Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

2016-06-27 Thread Tuukka Turunen 


> -Original Message-
> From: sean.harmer On Behalf Of Sean Harmer
> Sent: maanantaina 27. kesäkuuta 2016 11.46
> To: development@qt-project.org
> Cc: Tuukka Turunen <tuukka.turu...@qt.io>
> Subject: Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1
> packages
> 
> On Monday 27 June 2016 07:18:02 Tuukka Turunen wrote:
> > > -Original Message-
> > > From: Development [mailto:development-
> > > bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Sean
> > > bounces+Harmer
> > > Sent: perjantaina 24. kesäkuuta 2016 11.23
> > > To: development@qt-project.org
> > > Subject: Re: [Development] [Releasing] brown paper bag issue in Qt
> > > 5.6.1 packages
> > >
> > > -- clip ---
> > > This is why we have a process. How is this situation compatible with
> > > TQC's ISO
>  9001 certification?!
> > >
> >
> >
> > Hi Sean,
> >
> > Making a fix release fits well with the release process of the ISO
> > 9001 certification, no problems there.
> 
> ISO 9001 is about following the processes that you say you follow. This is
> clearly not the case here as a process was made up on the spot to do it
> quickly. This is clearly a non-conformance. Removing packages is clearly
> another.
> 

Deleting the package was an error that is fixed as soon as possible. It is not 
part of the process to do so. 

> I'm not disputing that a process for quick fix releases should be made, but
> the time to do this is not when there is a sudden need for it. That's when
> unforeseen mistakes slip through the cracks.
> 

I do agree that the process of making this kind of releases should be better 
documented and agreed upon by the various stakeholders. Release team has also 
earlier made similar ones, but mostly related to packaging problems.

> Had the decision to just cherry pick this one fix and apply the usual release
> process for a 5.6.2 had been made, the level of testing could have been
> reduced accordingly to speed up the process and a message put out saying to
> avoid 5.6.1 if you are using QML/Quick. With a 5.6.2 release coming shortly,
> users could have made the informed decision to stick with 5.6.0 until 5.6.2
> was ready. If the installer had the ability to downgrade as well as upgrade,
> this would be even easier.
> 

I think it would be best to have this discussion in the next release team 
meeting and in addition at QtCon. Changing the version number in Qt modules, 
re-doing all change files etc, takes time and especially when done so close to 
release would cause users possibly to miss the other changes in the logs. 

We need to have a process that is lightweight enough to make "hotfixes" when 
necessary. If the process of making for example a security fix is too time 
consuming, it will cause us not to use it as often as we perhaps should.

Yours,

Tuukka

> Cheers,
> 
> Sean
> 
> > In general, it is valuable to be able to make releases quickly to fix
> > e.g. a security vulnerability. The fastest way to do it is to push the
> > needed change (or changes) into the release branch, and create new
> > release directly from there. I do not have any strong opinion if the
> > number of the release should be x.y.z.1 , x.y.z-1 or even x.y.(z+1).
> > Earlier the notation has been -1, but if there is desire to change it
> > going forward, I do not think that is a problem.
> 
> > Yours,
> >
> > Tuukka
> >
> >
> >
> >
> > > Sean
> > > --
> > > Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK KDAB
> > > (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ)
> > > +46-
> > > 563-540090
> > > Mobile: +44 (0)7545 140604
> > > KDAB - Qt Experts
> > > ___
> > > Development mailing list
> > > Development@qt-project.org
> > > http://lists.qt-project.org/mailman/listinfo/development
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> --
> Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK KDAB
> (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-
> 563-540090
> Mobile: +44 (0)7545 140604
> KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

2016-06-27 Thread Sean Harmer 
On Monday 27 June 2016 07:18:02 Tuukka Turunen wrote:
> > -Original Message-
> > From: Development [mailto:development-
> > bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Sean Harmer
> > Sent: perjantaina 24. kesäkuuta 2016 11.23
> > To: development@qt-project.org
> > Subject: Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1
> > packages
> > 
> > -- clip --- 
> > This is why we have a process. How is this situation compatible with TQC's
> > ISO
 9001 certification?!
> > 
> 
> 
> Hi Sean,
> 
> Making a fix release fits well with the release process of the ISO 9001
> certification, no problems there. 

ISO 9001 is about following the processes that you say you follow. This is 
clearly not the case here as a process was made up on the spot to do it 
quickly. This is clearly a non-conformance. Removing packages is clearly 
another.

I'm not disputing that a process for quick fix releases should be made, but the 
time to do this is not when there is a sudden need for it. That's when 
unforeseen mistakes slip through the cracks.

Had the decision to just cherry pick this one fix and apply the usual release 
process for a 5.6.2 had been made, the level of testing could have been 
reduced accordingly to speed up the process and a message put out saying to 
avoid 5.6.1 if you are using QML/Quick. With a 5.6.2 release coming shortly, 
users could have made the informed decision to stick with 5.6.0 until 5.6.2 
was ready. If the installer had the ability to downgrade as well as upgrade, 
this would be even easier.

Cheers,

Sean
 
> In general, it is valuable to be able to make releases quickly to fix e.g. a
> security vulnerability. The fastest way to do it is to push the needed
> change (or changes) into the release branch, and create new release
> directly from there. I do not have any strong opinion if the number of the
> release should be x.y.z.1 , x.y.z-1 or even x.y.(z+1). Earlier the notation
> has been -1, but if there is desire to change it going forward, I do not
> think that is a problem.
 
> Yours,
> 
>   Tuukka 
> 
> 
> 
> 
> > Sean
> > --
> > Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK KDAB
> > (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-
> > 563-540090
> > Mobile: +44 (0)7545 140604
> > KDAB - Qt Experts
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

2016-06-27 Thread Tuukka Turunen 


> -Original Message-
> From: Development [mailto:development-
> bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Thiago
> Macieira
> Sent: maanantaina 27. kesäkuuta 2016 10.58
> To: development@qt-project.org
> Subject: Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1
> packages
> 
> On sábado, 25 de junho de 2016 21:24:12 PDT Thiago Macieira wrote:
> > On sexta-feira, 24 de junho de 2016 08:51:51 PDT Thiago Macieira wrote:
> > > On sexta-feira, 24 de junho de 2016 10:26:37 PDT Tuukka Turunen wrote:
> > > > Hi,
> > > >
> > > > I do not know why 5.6.1 has been deleted, but it is of course a mistake.
> > > > However, we need to make sure no-one accidentally takes it, so
> > > > maybe moving to archive is good approach?
> > >
> > > No, keep it in http://download.qt.io/official_releases/qt/5.6/,
> > > since it's an official release. Source code is enough though, we
> > > don't need the binaries.
> > >
> > > The solution for "make sure no one accidentally takes it" is to name
> > > the other release 5.6.2...
> >
> > Files are still not back yet.
> >
> > I've created a P0 task for the release team. Please solve this Monday.
> >
> > https://bugreports.qt.io/browse/QTBUG-54351
> 
> This is your daily reminder that the files are not back yet. Please address 
> it by
> EOB today.
> 
> I will send a new reminder when I wake up, if they are not there.
> 
> I will send reminders every couple of hours if I am in front of my computer
> while the files are not there.
> 

As said before, removal of the earlier release was an error, which will be 
fixed as soon as possible.

Feel free to send reminders to ML, but it really does not make the repos sync 
any faster.
 
Yours,

Tuukka

> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

2016-06-27 Thread Thiago Macieira 
On sábado, 25 de junho de 2016 21:24:12 PDT Thiago Macieira wrote:
> On sexta-feira, 24 de junho de 2016 08:51:51 PDT Thiago Macieira wrote:
> > On sexta-feira, 24 de junho de 2016 10:26:37 PDT Tuukka Turunen wrote:
> > > Hi,
> > > 
> > > I do not know why 5.6.1 has been deleted, but it is of course a mistake.
> > > However, we need to make sure no-one accidentally takes it, so maybe
> > > moving
> > > to archive is good approach?
> > 
> > No, keep it in http://download.qt.io/official_releases/qt/5.6/, since it's
> > an official release. Source code is enough though, we don't need the
> > binaries.
> > 
> > The solution for "make sure no one accidentally takes it" is to name the
> > other release 5.6.2...
> 
> Files are still not back yet.
> 
> I've created a P0 task for the release team. Please solve this Monday.
> 
> https://bugreports.qt.io/browse/QTBUG-54351

This is your daily reminder that the files are not back yet. Please address it 
by EOB today.

I will send a new reminder when I wake up, if they are not there.

I will send reminders every couple of hours if I am in front of my computer 
while the files are not there.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

2016-06-27 Thread Thiago Macieira 
On segunda-feira, 27 de junho de 2016 07:18:02 PDT Tuukka Turunen wrote:
> In general, it is valuable to be able to make releases quickly to fix e.g. a
> security vulnerability. The fastest way to do it is to push the needed
> change (or changes) into the release branch, and create new release
> directly from there. I do not have any strong opinion if the number of the
> release should be x.y.z.1 , x.y.z-1 or even x.y.(z+1). Earlier the notation
> has been -1, but if there is desire to change it going forward, I do not
> think that is a problem.

Correction, no, there was no earlier notation because we've never done this 
before.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

2016-06-27 Thread Tuukka Turunen 


> -Original Message-
> From: Development [mailto:development-
> bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Sean Harmer
> Sent: perjantaina 24. kesäkuuta 2016 11.23
> To: development@qt-project.org
> Subject: Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1
> packages
> 
> -- clip --- 
> This is why we have a process. How is this situation compatible with TQC's ISO
> 9001 certification?!
> 

Hi Sean,

Making a fix release fits well with the release process of the ISO 9001 
certification, no problems there. 

In general, it is valuable to be able to make releases quickly to fix e.g. a 
security vulnerability. The fastest way to do it is to push the needed change 
(or changes) into the release branch, and create new release directly from 
there. I do not have any strong opinion if the number of the release should be 
x.y.z.1 , x.y.z-1 or even x.y.(z+1). Earlier the notation has been -1, but if 
there is desire to change it going forward, I do not think that is a problem.

Yours,

Tuukka 



> Sean
> --
> Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK KDAB
> (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-
> 563-540090
> Mobile: +44 (0)7545 140604
> KDAB - Qt Experts
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

2016-06-25 Thread Thiago Macieira 
On sexta-feira, 24 de junho de 2016 08:50:01 PDT Thiago Macieira wrote:
> I disagree. This problem is going to affect Support a lot more, as it will
> be difficult to get the actual version number from people. When customers
> come for support and say they have 5.6.1, Support will have to tell the
> customer "please re-download and install the new version" because they
> won't be sure that the customer didn't download the old version last week.
> 
> As for support on the IRC channel and mailing list,s if we don't change the
> .qmake.conf file, I will simply tell people to *downgrade* to 5.6.0 or wait
> for 5.6.2. Think of packagers that don't pay that good an attention to this
> mailing list. They may not realise that it's a different version and may
> simply call it 5.6.1.

On IRC just now:

20:59 < nurupo> what does "-1" in "5.6.1-1" mean?
21:00 < nurupo> it always was major.minor.patch, with the API/ABI 
compatibility relation between them well defined
21:00 < nurupo> but suddenly there is this "-1"

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

2016-06-25 Thread Thiago Macieira 
On sexta-feira, 24 de junho de 2016 08:51:51 PDT Thiago Macieira wrote:
> On sexta-feira, 24 de junho de 2016 10:26:37 PDT Tuukka Turunen wrote:
> > Hi,
> > 
> > I do not know why 5.6.1 has been deleted, but it is of course a mistake.
> > However, we need to make sure no-one accidentally takes it, so maybe
> > moving
> > to archive is good approach?
> 
> No, keep it in http://download.qt.io/official_releases/qt/5.6/, since it's
> an official release. Source code is enough though, we don't need the
> binaries.
> 
> The solution for "make sure no one accidentally takes it" is to name the
> other release 5.6.2...

Files are still not back yet.

I've created a P0 task for the release team. Please solve this Monday.

https://bugreports.qt.io/browse/QTBUG-54351

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

2016-06-24 Thread Thiago Macieira 
On sexta-feira, 24 de junho de 2016 10:26:37 PDT Tuukka Turunen wrote:
> Hi,
> 
> I do not know why 5.6.1 has been deleted, but it is of course a mistake.
> However, we need to make sure no-one accidentally takes it, so maybe moving
> to archive is good approach?

No, keep it in http://download.qt.io/official_releases/qt/5.6/, since it's an 
official release. Source code is enough though, we don't need the binaries.

The solution for "make sure no one accidentally takes it" is to name the other 
release 5.6.2...

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

2016-06-24 Thread Thiago Macieira 
On sexta-feira, 24 de junho de 2016 08:33:39 PDT Lars Knoll wrote:
> >2) because the .qmake.conf file in qtdeclarative contains the same version
> > number for two releases. It's impossible for regular people to tell us
> >which version they have compiled if they have already erased the source
> >tarballs.
> 
> True, but I don’t think it’ll be a problem in practice. Let’s however make
> sure we get this right next time.

I disagree. This problem is going to affect Support a lot more, as it will be 
difficult to get the actual version number from people. When customers come for 
support and say they have 5.6.1, Support will have to tell the customer 
"please re-download and install the new version" because they won't be sure 
that the customer didn't download the old version last week.

As for support on the IRC channel and mailing list,s if we don't change the 
.qmake.conf file, I will simply tell people to *downgrade* to 5.6.0 or wait for 
5.6.2. Think of packagers that don't pay that good an attention to this 
mailing list. They may not realise that it's a different version and may 
simply call it 5.6.1.

I will disavow any and all QML-related problems in 5.6.1 in IRC and the 
interest ML if it sticks to the same version number.
 
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

2016-06-24 Thread Tuukka Turunen 

Hi,

I do not know why 5.6.1 has been deleted, but it is of course a mistake. 
However, we need to make sure no-one accidentally takes it, so maybe moving to 
archive is good approach?

Let's fix that next week the latest. Today is a national holiday in Finland, so 
we'll need to survive through the weekend.

Yours,

Tuukka

Lähettäjä: Ralf Nolden<mailto:nol...@kde.org>
Lähetetty: ‎24.‎6.‎2016 12:43
Vastaanottaja: development@qt-project.org<mailto:development@qt-project.org>
Aihe: Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

Am Freitag, 24. Juni 2016, 08:33:39 schrieb Lars Knoll:
> On 24/06/16 09:41, "Development on behalf of Thiago Macieira"
> <development-bounces+lars.knoll=qt...@qt-project.org on behalf of
> thiago.macie...@intel.com> wrote:

> >At the very least, BRING BACK 5.6.1 to
> >http://download.qt.io/official_releases/qt/5.6/
> >
> >Don't EVER delete releases. That's poor release practice and poor open
> >source
 practice. This is the same rule as "never silently replace
> >release files".
> >I'm serious. Bring it back, now.
>
>
> Well, I didn’t know 5.6.1 is gone. That’s clearly wrong.


Can that please be fixed before the weekend ?


Thanks.
>
> Lars
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

--
Kind regards,

Ralf Nolden

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

2016-06-24 Thread Ralf Nolden 
Am Freitag, 24. Juni 2016, 08:33:39 schrieb Lars Knoll:
> On 24/06/16 09:41, "Development on behalf of Thiago Macieira"
>  thiago.macie...@intel.com> wrote:

> >At the very least, BRING BACK 5.6.1 to 
> >http://download.qt.io/official_releases/qt/5.6/
> >
> >Don't EVER delete releases. That's poor release practice and poor open
> >source 
 practice. This is the same rule as "never silently replace
> >release files". 
> >I'm serious. Bring it back, now.
> 
> 
> Well, I didn’t know 5.6.1 is gone. That’s clearly wrong.


Can that please be fixed before the weekend ?


Thanks.
> 
> Lars
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Kind regards,

Ralf Nolden

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

2016-06-24 Thread Lars Knoll 





On 24/06/16 09:41, "Development on behalf of Thiago Macieira" 
 wrote:

>On sexta-feira, 24 de junho de 2016 06:49:56 PDT Lars Knoll wrote:
>> On 24/06/16 02:12, "Development on behalf of Thiago Macieira"
>> > thiago.macie...@intel.com> wrote:
> 
>> 
>> >On terça-feira, 21 de junho de 2016 23:37:57 PDT Thiago Macieira wrote:
>> >
>> >> On terça-feira, 21 de junho de 2016 16:42:14 PDT Thiago Macieira wrote:
>> >> 
>> >> > I propose that we delete the bad tag, retag and rerelease with a
>> >> > better
>> >> > name.
>> >> 
>> >> 
>> >> Also: update MODULE_VERSION qtdeclarative/.qmake.conf. It MUST be
>> >> different 
> from the original 5.6.1 version.
>> >
>> >
>> >What action is going to be taken to fix this mistake?
>> >
>> >Suggestion:
>> >
>> > * delete the v5.6.1-1 tag immediately
>> > * immediately retract all source and binary releases with "-1" in the
>> > name
>> > * modify qtdeclarative's .qmake.conf to say MODULE_VERSION = 5.6.2
>> > * tag that v5.6.2, update qt5.git and tag it v5.6.2
>> > * rebuild binaries
>> > * release them and source
>> >
>> >
>> >The tag v5.6.2 will be skipped in all the other modules. We update all of 
>> >their MODULE_VERSION to 5.6.3.
>> 
>> 
>> What’s the point? Create ourselves man weeks worth of work and completely
>> confuse all our users for what exactly? 
>
>For two reasons:
>
>1) because every Linux packager will call it 5.6.1.1, not 5.6.1-1. The tag is 
>*wrong*. Please delete the tag, regardless of whether new packages are 
>created, recreate it with the *right* name.

Yes, Linux packagers will call it 5.6.1.1, and I agree that’s what we should 
have called it as well. 

I have nothing fundamental against changing the tag to 5.6.1.1, but I don’t see 
a huge gain neither. It’s just a tag in our repo’s. 

>2) because the .qmake.conf file in qtdeclarative contains the same version 
>number for two releases. It's impossible for regular people to tell us which 
>version they have compiled if they have already erased the source tarballs.

True, but I don’t think it’ll be a problem in practice. Let’s however make sure 
we get this right next time.

> 
>> Let’s have a discussion at QtCS how to best do things in the future, but
>> this is not worth it.
>
>We already have a procedure for making a release and all we had to do was 
>follow it. In any case, my problem was the release number, not the procedure. 
>All I want is the proper number now.
>
>At the very least, BRING BACK 5.6.1 to 
>http://download.qt.io/official_releases/qt/5.6/
>
>Don't EVER delete releases. That's poor release practice and poor open source 
>practice. This is the same rule as "never silently replace release files".
>
>I'm serious. Bring it back, now.

Well, I didn’t know 5.6.1 is gone. That’s clearly wrong.

Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

2016-06-24 Thread Thiago Macieira 
On sexta-feira, 24 de junho de 2016 06:49:56 PDT Lars Knoll wrote:
> On 24/06/16 02:12, "Development on behalf of Thiago Macieira"
>  thiago.macie...@intel.com> wrote:
 
> 
> >On terça-feira, 21 de junho de 2016 23:37:57 PDT Thiago Macieira wrote:
> >
> >> On terça-feira, 21 de junho de 2016 16:42:14 PDT Thiago Macieira wrote:
> >> 
> >> > I propose that we delete the bad tag, retag and rerelease with a
> >> > better
> >> > name.
> >> 
> >> 
> >> Also: update MODULE_VERSION qtdeclarative/.qmake.conf. It MUST be
> >> different 
 from the original 5.6.1 version.
> >
> >
> >What action is going to be taken to fix this mistake?
> >
> >Suggestion:
> >
> > * delete the v5.6.1-1 tag immediately
> > * immediately retract all source and binary releases with "-1" in the
> > name
> > * modify qtdeclarative's .qmake.conf to say MODULE_VERSION = 5.6.2
> > * tag that v5.6.2, update qt5.git and tag it v5.6.2
> > * rebuild binaries
> > * release them and source
> >
> >
> >The tag v5.6.2 will be skipped in all the other modules. We update all of 
> >their MODULE_VERSION to 5.6.3.
> 
> 
> What’s the point? Create ourselves man weeks worth of work and completely
> confuse all our users for what exactly? 

For two reasons:

1) because every Linux packager will call it 5.6.1.1, not 5.6.1-1. The tag is 
*wrong*. Please delete the tag, regardless of whether new packages are 
created, recreate it with the *right* name.

2) because the .qmake.conf file in qtdeclarative contains the same version 
number for two releases. It's impossible for regular people to tell us which 
version they have compiled if they have already erased the source tarballs.
 
> Let’s have a discussion at QtCS how to best do things in the future, but
> this is not worth it.

We already have a procedure for making a release and all we had to do was 
follow it. In any case, my problem was the release number, not the procedure. 
All I want is the proper number now.

At the very least, BRING BACK 5.6.1 to 
http://download.qt.io/official_releases/qt/5.6/

Don't EVER delete releases. That's poor release practice and poor open source 
practice. This is the same rule as "never silently replace release files".

I'm serious. Bring it back, now.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

2016-06-24 Thread Lars Knoll 

On 24/06/16 02:12, "Development on behalf of Thiago Macieira" 
 wrote:

>On terça-feira, 21 de junho de 2016 23:37:57 PDT Thiago Macieira wrote:
>> On terça-feira, 21 de junho de 2016 16:42:14 PDT Thiago Macieira wrote:
>> > I propose that we delete the bad tag, retag and rerelease with a better
>> > name.
>> 
>> Also: update MODULE_VERSION qtdeclarative/.qmake.conf. It MUST be different 
>> from the original 5.6.1 version.
>
>What action is going to be taken to fix this mistake?
>
>Suggestion:
> * delete the v5.6.1-1 tag immediately
> * immediately retract all source and binary releases with "-1" in the name
> * modify qtdeclarative's .qmake.conf to say MODULE_VERSION = 5.6.2
> * tag that v5.6.2, update qt5.git and tag it v5.6.2
> * rebuild binaries
> * release them and source
>
>The tag v5.6.2 will be skipped in all the other modules. We update all of 
>their MODULE_VERSION to 5.6.3.

What’s the point? Create ourselves man weeks worth of work and completely 
confuse all our users for what exactly? 

Let’s have a discussion at QtCS how to best do things in the future, but this 
is not worth it.

Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

2016-06-23 Thread Thiago Macieira 
On terça-feira, 21 de junho de 2016 23:37:57 PDT Thiago Macieira wrote:
> On terça-feira, 21 de junho de 2016 16:42:14 PDT Thiago Macieira wrote:
> > I propose that we delete the bad tag, retag and rerelease with a better
> > name.
> 
> Also: update MODULE_VERSION qtdeclarative/.qmake.conf. It MUST be different 
> from the original 5.6.1 version.

What action is going to be taken to fix this mistake?

Suggestion:
 * delete the v5.6.1-1 tag immediately
 * immediately retract all source and binary releases with "-1" in the name
 * modify qtdeclarative's .qmake.conf to say MODULE_VERSION = 5.6.2
 * tag that v5.6.2, update qt5.git and tag it v5.6.2
 * rebuild binaries
 * release them and source

The tag v5.6.2 will be skipped in all the other modules. We update all of 
their MODULE_VERSION to 5.6.3.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

2016-06-22 Thread Thiago Macieira 
On quarta-feira, 22 de junho de 2016 06:28:12 PDT Jani Heikkinen wrote:
> Hi,
> 
> 
> To be clear: There isn't version bump in qt, it is still 5.6.1.

Are the source packages the same? No? Then it's a new version.

> We just
> re-packed the release from '5.6.1' branch with that new change for fixing
> QTBUG-53761 included (https://codereview.qt-project.org/#/c/162677/). In
> tags & packages we used 5.6.1-1 to make difference with original and
> updated ones & to be able to identify if user has original or re-packed
> version in the use. Of course we could just move v5.6.1 tag in declarative
> and ignore v5.6.1-1 and that's it...

We could do that, yes:
 * no new qtdeclarative source package
 * cherry-pick the patch to the tree used for the binaries, release
 * update the binary relase version

I just think it's a bad idea and would cause confusion too.

But I'm asking that we Do The Right Thing, instead of trying to find the 
solution with the least amount of effort. We own up to our mistakes and then 
we fix the correctly.

> But It has done this way now. Ok, if tag or something is really broken let's
> just correct that but otherwise just live with this now. And for the future
> lets just agree the way to work with this kind of 'brown paper bug issue'.

Let's agree on no more "brown paper bag fixes". Let's not rush into more 
mistakes. This only happened because we tried to find the solution with the 
least amount of effort instead of doing the proper, established way of 
creating new releases.

> In my opinion bumping version numbers and doing totally new release because
> of just one fix is too heavy. I think we should have a way to produce this
> kind of update with 'simple hot fix ' easily and quickly without re-doing
> whole release in case of this kind of blocker.

If we have a light-weight procedure, great, let's use it.

But we don't. And creating one the moment we need a quick fix is a bad idea, 
because we're going down untested paths and creating more problems in the 
process, as the current case has shown.

I think we should have a light-weight procedure. Let's investigate it when we 
have the time to do it.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

2016-06-22 Thread Thiago Macieira 
On quarta-feira, 22 de junho de 2016 06:48:39 PDT Lars Knoll wrote:
> >Also: update MODULE_VERSION qtdeclarative/.qmake.conf. It MUST be different
> > from the original 5.6.1 version.
> 
> Why? 

So that when someone reports an issue, we can tell from the sources whether it 
included the fix or not.

> It’s one patch for a bug that can hit quite some of our users, otherwise
> everything is identical. 

Hence updating only qtdeclarative's version number, not everything else.
 
> Let’s for a second assume, we had not released an update, but added this to
> the known issues page and released 5.6.2 some time later this year. What
> would have happened is that all Linux distributions would have picked up
> that one patch, added it to their packages, and recompiled 5.6.1. The .so
> version number inside the distributions would still be 5.6.1, and you
> wouldn’t know the difference looking from the outside. The only thing that
> changes when the Linux distributions do such an update is the version
> number of the package, not of the .so’s inside.

Exactly. The .so don't need to have their number changed, but the package 
does. So we need to update .qmake.conf. Whether that updates the .so file names 
or not is irrelevant.

MODULE_VERSION = 5.6.1.1 will produce .so.5.6.1
 
> We basically do the same here. Yes, we can argue whether the tag should be
> 5.6.1-1 or 5.6.1.1, but it doesn’t change the fact that I don’t really see
> a problem in keeping the .so version for this case.
 
Nor I.

So let's change the tag and the MODULE_VERSION. It's important that if I ask a 
user, they can check their source code and see which one of the sources they 
downloaded, after they removed the original .tar.gz file.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

2016-06-22 Thread Oswald Buddenhagen 
On Wed, Jun 22, 2016 at 06:48:39AM +, Lars Knoll wrote:
> The only thing that changes when the Linux distributions do such an
> update is the version number of the package, not of the .so’s inside.
> 
> We basically do the same here.
> 
but we can't, because we are upstream. if the qt company's release team
does not act directly on behalf of the qt project, then this must be
reflected in the version control system, as explicitly stated in the
branch policy: the tag is v5.6.1-tqtc-1, and it is *not* forward-merged
to 5.6.


On Wed, Jun 22, 2016 at 06:54:54AM +, Tuukka Turunen wrote:
> Users need it and it is ready, so we really need to release this now.
> 
it's undoubtedly necessary, but the fact that it is ready does not
authorize us as a company to violate the agreed upon rules.


the rest of the mail dissects the technicalities. it's unnecessary to
read it if you accept the conclusions reached so far.


On Wed, Jun 22, 2016 at 06:28:12AM +, Jani Heikkinen wrote:
> To be clear: There isn't version bump in qt, it is still 5.6.1. We
> just re-packed the release from '5.6.1' branch with that new change
> for fixing QTBUG-53761 included.
>
you're kinda trying to make the argument that the packages are a patched
downstream version, but that seems quite unconvincing: we *are*
upstream. this is reinforced by the fact that our installers are the
primary advertized distribution medium. and it's sealed by you creating
an upstream tag in the mainline repository.

> In my opinion bumping version numbers and doing totally new release
> because of just one fix is too heavy. I think we should have a way to
> produce this kind of update with 'simple hot fix' easily and quickly
> without re-doing whole release in case of this kind of blocker.
> 
you're trying to both eat the cake and have it.

it has different contents (which is reflected by a different tag), so it
*is* a different version. it doesn't matter how small the difference is.

On Wed, Jun 22, 2016 at 10:20:15AM +, Jani Heikkinen wrote:
> Actually there is quite many things to do for the new release (agree
> the content, get the agreed content in etc.) but if we are assuming
> content is agreed to be one change + version bumps then the flow is
> pretty much as follows:
> 
> 1. Create new branch for the release (not needed if updating existing
> release)
> 
not necessary, as already pointed out. the existence of a release branch
is a convenience, not a requirement. the name matching the released
version is luxury (we could have release and release-lts branches just
as well).

> 2. Do version bumps for submodules in that new branch + create a fix
> in that new branch (not needed if updating existing release)
> 
while it would be somewhat weird, we could bump only qtdeclarative and
qt5, keeping the version number of the other modules the same. but
anyway, see next point.

> 3. Integrate fix + version bumps. When we are doing new release we
> need to bump version in each submodule as well. Knowing our CI
> stability it will take a while when all version bumps are in
> submodules. Without version bump we just need to integrate that one
> change in one submodule
> 
as you could have figured out by just looking at the commits, version
bumps are direct-pushed by my script (except repos that happen to be
busy for extended periods of time while i do the bumping, typically
qtbase). so this is a non-argument.

> 4. Integrate submodule changes in qt5.git. If all modules are changed
> this step will most probably fail few times because of CI instability
> (flaky tests, network issues etc). With change in one submodule this
> is most probably much easier & will go through much quicker
> 
i don't see how changing at most the version number in all other modules
could delay the integration.

> 5. Merge qt5.git in our super repository containing qt5.git +
> enterprise features.
> 
> 6. Run packaging tools for src and binary packages (patch content,
> package content in suitable form for installers).
> 
> 7. Update packaging configurations. If we are doing new release we
> need to create all new packaging configurations for that.
>
i'll buy that, but this indicates just how broken the system is. cloning
a branch config should be a matter of a single near-trivial commit.

the previous two points also just show how bad our system is. luckily,
this is finally being worked on.

> 8. Update release test automation configurations and tests. (not
> needed if updating existing release)
> 
> 9. Create packages for the release (Online repository and offline
> inataller packages, LGPL and commercial ones)
> 
same again. broken infrastructure.

> 10. Test the release. If we update existing release with one change it
> is much easier to test.
>
see point 4.


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

2016-06-22 Thread Tuukka Turunen 


> -Original Message-
> From: Development [mailto:development-
> bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Lars Knoll
> Sent: keskiviikkona 22. kesäkuuta 2016 9.49
> To: Thiago Macieira <thiago.macie...@intel.com>; development@qt-
> project.org
> Subject: Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1
> packages
> 
> 
> On 22/06/16 08:37, "Development on behalf of Thiago Macieira"
> <development-bounces+lars.knoll=qt...@qt-project.org on behalf of
> thiago.macie...@intel.com> wrote:
> 
> >On terça-feira, 21 de junho de 2016 16:42:14 PDT Thiago Macieira wrote:
> >> I propose that we delete the bad tag, retag and rerelease with a
> >> better name.
> >
> >Also: update MODULE_VERSION qtdeclarative/.qmake.conf. It MUST be
> >different from the original 5.6.1 version.
> 
> Why?
> 
> It’s one patch for a bug that can hit quite some of our users, otherwise
> everything is identical.
> 
> Let’s for a second assume, we had not released an update, but added this to
> the known issues page and released 5.6.2 some time later this year. What
> would have happened is that all Linux distributions would have picked up
> that one patch, added it to their packages, and recompiled 5.6.1. The .so
> version number inside the distributions would still be 5.6.1, and you wouldn’t
> know the difference looking from the outside. The only thing that changes
> when the Linux distributions do such an update is the version number of the
> package, not of the .so’s inside.
> 
> We basically do the same here. Yes, we can argue whether the tag should be
> 5.6.1-1 or 5.6.1.1, but it doesn’t change the fact that I don’t really see a
> problem in keeping the .so version for this case.
> 

+1

The issue is severe and due to the summer holidays and work needed to prepare 
for Qt 5.8 it is not possible to make Qt 5.6.2 full release.

Furthermore, we have now everything ready and tested for releasing the Qt 
5.6.1-1 today, including full offline and online binary packages. 

Users need it and it is ready, so we really need to release this now.

Yours,

Tuukka


> Cheers,
> Lars
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

2016-06-22 Thread Lars Knoll 

On 22/06/16 08:37, "Development on behalf of Thiago Macieira" 
 wrote:

>On terça-feira, 21 de junho de 2016 16:42:14 PDT Thiago Macieira wrote:
>> I propose that we delete the bad tag, retag and rerelease with a better
>> name.
>
>Also: update MODULE_VERSION qtdeclarative/.qmake.conf. It MUST be different 
>from the original 5.6.1 version.

Why? 

It’s one patch for a bug that can hit quite some of our users, otherwise 
everything is identical. 

Let’s for a second assume, we had not released an update, but added this to the 
known issues page and released 5.6.2 some time later this year. What would have 
happened is that all Linux distributions would have picked up that one patch, 
added it to their packages, and recompiled 5.6.1. The .so version number inside 
the distributions would still be 5.6.1, and you wouldn’t know the difference 
looking from the outside. The only thing that changes when the Linux 
distributions do such an update is the version number of the package, not of 
the .so’s inside.

We basically do the same here. Yes, we can argue whether the tag should be 
5.6.1-1 or 5.6.1.1, but it doesn’t change the fact that I don’t really see a 
problem in keeping the .so version for this case.

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

2016-06-22 Thread Thiago Macieira 
On terça-feira, 21 de junho de 2016 16:42:14 PDT Thiago Macieira wrote:
> I propose that we delete the bad tag, retag and rerelease with a better
> name.

Also: update MODULE_VERSION qtdeclarative/.qmake.conf. It MUST be different 
from the original 5.6.1 version.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

2016-06-21 Thread Ralf Nolden 
Am Mittwoch, 22. Juni 2016, 05:03:28 schrieb Jani Heikkinen:
> Hi!

> But if there is really some reason why v5.6.1-1 don't work and v.5.6.1.1
> would work then it is really ok for me to change the tag. But let's don't
> change that just because of opinions...
The naming scheme for alpha, beta, rc's is - so the 
packager scripts get all confused up assuming it's non-standard and not a 
patch release. If 5.6.2 is impossible, please go with 5.6.1.1


> And if for some reason it was too difficult to bump everything that was
> scheduled for 5.6.2 to 5.6.3, then at the very least we should have used
> v5.6.1.1, which is probably what everyone making Qt packages will need to
> use since a dash is completely unacceptable in release versions.
Ack
> 
> I propose that we delete the bad tag, retag and rerelease with a better
> name.
Ack
> 
> Let's not make rash decisions again.
> 
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Kind regards,

Ralf Nolden

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

2016-06-21 Thread Jani Heikkinen 
Hi!


Actually https://bugreports.qt.io/browse/QTBUG-53761 is a blocker. Priority 
isn't correct at the moment but in reality the bug is preventing any bigger and 
a bit complex applications working correctly. Unfortunately bug isn't 
describing that well enough :(


That's why we need to update the packages just with that one fix. And that's 
why it isn't new 5.6.2 release (in my opinion), it is just 5.6.1 + hotfix. 
There was already request 'because you are doing new release please include 
this fixes' etc :) and that is unfortunately impossible now, just before summer 
holidays, sorry.


And what comes to tag: we have used '-1' tag earlier (in enterprise 
repositories) and we didn't see any reason to change that 'hotfix' tagging 
scheme. It was discussed in irc as well but at least for me no-one really says 
why '-1' pattern is wrong. There was just opinions for and against and because 
we have used '-1' tag earlier it was selected this time as well. Another reason 
was the package naming: We have some tools which cannot handle 5.6.1.1 but can 
handle 5.6.1-1 in package names and it is better to use same format in the tag 
what is used in package names.


But if there is really some reason why v5.6.1-1 don't work and v.5.6.1.1 would 
work then it is really ok for me to change the tag. But let's don't change that 
just because of opinions...


br,

Jani






From: Development <development-bounces+jani.heikkinen=qt...@qt-project.org> on 
behalf of Thiago Macieira <thiago.macie...@intel.com>
Sent: Wednesday, June 22, 2016 2:42 AM
To: releas...@qt-project.org
Cc: development@qt-project.org
Subject: Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 
packages

On quinta-feira, 16 de junho de 2016 10:38:02 PDT Jani Heikkinen wrote:
> Unfortunately we noticed https://bugreports.qt.io/browse/QTBUG-53761 is
> actually a brown paper bag issue for Qt 5.6.1 release. That's why we need
> to update release packages with change
> https://codereview.qt-project.org/#/c/162677/ . We will "release" new
> packages (Qt 5.6.1-1) as soon as fix is in qt5.git & we have created and
> tested the packages from new content. It is much easier and safer to select
> that option instead of releasing Qt 5.6.2 before summer vacations.

I've just noticed this email.

QTBUG-53761 is not P0, so it did not warrant new packages.

The naming for the new tag is totally unacceptable. It should have been
v5.6.2. We own up to our errors. If 5.6.1 wasn't good enough for anyone, then
we release v5.6.2 immediately after.

And if for some reason it was too difficult to bump everything that was
scheduled for 5.6.2 to 5.6.3, then at the very least we should have used
v5.6.1.1, which is probably what everyone making Qt packages will need to use
since a dash is completely unacceptable in release versions.

I propose that we delete the bad tag, retag and rerelease with a better name.

Let's not make rash decisions again.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

2016-06-21 Thread Thiago Macieira 
On quinta-feira, 16 de junho de 2016 10:38:02 PDT Jani Heikkinen wrote:
> Unfortunately we noticed https://bugreports.qt.io/browse/QTBUG-53761 is
> actually a brown paper bag issue for Qt 5.6.1 release. That's why we need
> to update release packages with change
> https://codereview.qt-project.org/#/c/162677/ . We will "release" new
> packages (Qt 5.6.1-1) as soon as fix is in qt5.git & we have created and
> tested the packages from new content. It is much easier and safer to select
> that option instead of releasing Qt 5.6.2 before summer vacations.

I've just noticed this email.

QTBUG-53761 is not P0, so it did not warrant new packages.

The naming for the new tag is totally unacceptable. It should have been 
v5.6.2. We own up to our errors. If 5.6.1 wasn't good enough for anyone, then 
we release v5.6.2 immediately after.

And if for some reason it was too difficult to bump everything that was 
scheduled for 5.6.2 to 5.6.3, then at the very least we should have used 
v5.6.1.1, which is probably what everyone making Qt packages will need to use 
since a dash is completely unacceptable in release versions.

I propose that we delete the bad tag, retag and rerelease with a better name.

Let's not make rash decisions again.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development