Re: [Development] Nominating Assam Boudjelthia as Approver

[Kari Oikarinen]

On 19.3.2020 11.25, Ville Voutilainen wrote:

Patches here: 
https://codereview.qt-project.org/q/owner:assam.boudjelthia%2540qt.io

Assam has been doing great work on Android, qemu, boot2qt,
and a whole bunch of things. If things go as planned, he will
be our Android maintainer.


+1. Teammate disclaimer, but Assam has indeed been doing great work.

--
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Arttu Tarkiainen as approver

[Kari Oikarinen]

Seconding approver status proposals can officially be done by approvers
and maintainers. As far as I can see, Tino, you are not one, so this
doesn't count officially.

See 
https://quips-qt-io.herokuapp.com/quip-0002.html#how-to-become-an-approver


+1 for Arttu's approvership.

On 11.3.2020 7.35, Tino Pyssysalo wrote:

+1

--

Tino Pyssysalo

Senior Product Manager

The Qt Company

On 10.3.2020, 14.00, "Development on behalf of Katja Marttila" 
 on behalf of 
katja.martt...@qt.io > wrote:


Hi all,

I’d like to nominate Arttu Tarkiainen as approver for the Qt Project.

Arttu has been working in the installer team as a SW developer since he 
joined the Qt Company about one year ago. First as a trainee and 
currently as full-time employee. Arttu has been focusing mainly to 
improve and maintain Installer Framework and proven to be very skilful 
developer. I’ll trust that he will use the approver rights responsibly 
and follow the Qt guidelines.


Here is the list of his changes:

     https://codereview.qt-project.org/q/owner:arttu.tarkiainen%2540qt.io

Br,

Katja Marttila

Software Engineer| Maintainer of Installer Framework

The Qt Company | Finland | Oulu


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



--
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Kari Oikarinen]

On 15.2.2020 16.23, Marc Mutz via Development wrote:
 > Hi,
 >
 > C++20 will contain new classes with emit() member functions
 > (wg21.link/P0053). While that will only pose problems for users that
 > include the new  header after (almost) any Qt header, this
 > should serve as a second shot across the bows (after namespace
 > boost::signals) that we should change something.

This serves as proof that our custom keywords cause issues occasionally,
but combined use of  and Qt won't be that common.

 >
 > To that effect, I'd like to propose that we switch the default for
 > QT_NO_KEYWORDS around. I'd so this in three phases:
 >
 > 1. phase
 >   a. Add CONFIG += keywords (or the CMake equivalent) to act as an
 > antagonist for no_keywords.
 >   b. Change the documentation, examples and Qt implementation to use the
 > Q_ macros
 >
 > In this case, they just cancel each other out. This is just so you can
 > already express the intent to continue to use lowercase keywords by
 > saying CONFIG += keywords. It also makes sure that next generation of Qt
 > programmers grows up with the Q_ macros, so they don't squint their eyes
 > when they see
 >
 > Q_EMIT valueChanged(m_value);
 >
 > 2. phase
 >   a. Make no_keywords the default
 >   b. Change the documentation accordingly
 >   c. the QT_NO_KEYWORDS macro is left untouched
 >
 > In this phase, projects that use qmake (or by some other means inherit
 > Qt's default)
 >
 > 3. phase
 >   a. Replace QT_NO_KEYWORDS with a new macro QT_USE_KEYWORDS (or 
somesuch).
 >   b. Change the documentation accordingly
 >
 > In this phase, even projects using not using Qt's defaults would switch
 > defaults.

This plan requires everyone to drop the use of our custom keywords in
their code or to enable a new define to compile source code that worked
previously. As a backward-incompatible change I think it needs a strong
justification.

A couple of conflicts during 20 years that can be resolved with
equivalent effort (QT_NO_EMIT or QT_NO_KEYWORDS) but are only
encountered pretty rarely don't seem like a strong enough reasons to me.
Isn't the way to cause the least pain for our users to do nothing in
this case? The effort seems to be the same, it's just whether we impose
it on everyone or just the people encountering conflicts.

The rest of the thread has had a lot of discussion on what the possible
alternatives to annotating signal emissions could be or whether such a
thing is necessary at all.

But I think evaluating whether this warrants a move at all should be
considered more than it has. Alternatives may not be relevant if we're
not going to get rid of `emit` being defined by default.

 >
 > We can then stop there, or we use the years to come to decide how we
 > want to transition off the macro stuff and consult with ISO C++ so they
 > can work with us to give us the functionality to do so (meta-classes,
 > qt::emit with overloaded whitespace operator, whatever).
 >
 > I think it's clear that, as it is now, where for two years such a
 > problem exists in the IS and doesn't get detected by "the Qt project",
 > for a certain definition thereof, and only comes up by chance encounter
 > at the last day of the last meeting before C++20 is "done", it cannot
 > continue. Or, if it continues, Qt will be bitten more and more by stuff
 > ISO C++ does. If ISO C++'s estimate for C++ programmers and TQC's claim
 > for Qt developers are both correct, we're looking at a size of the
 > intersection of the two groups of over 20% of all C++ programmers. I
 > happen to be firmly rooted in both, and I'd be sad to see the two
 > separate ways even more than they have done in the past.

We should co-operate better in the future. We definitely should *not*
add any new custom keywords. But is it worth tackling something very
common that causes problems relatively rarely?

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Requesting a module for Qt JSON RPC and Qt Language Server

[Kari Oikarinen]

On 16.12.2019 17.39, Ulf Hermann wrote:
> Hi,
> 
> I would like to request a new module and repository for an
> implementation of the JSON RPC and Language Server protocols:
> 
> Name of the repository: qt/qtlanguageserver.git
> Description: An implementation of the language server protocol
> Responsible person: Ulf Hermann
> Gerrit user/email: ulf.herm...@qt.io
> 
> You can see my previous work on this in the context of the QML language
> server here:
> 
> https://codereview.qt-project.org/c/qt/qtdeclarative/+/243394
> https://codereview.qt-project.org/c/qt/qtdeclarative/+/233778
> 
> The relevant specifications can be found at:
> 
> https://www.jsonrpc.org/specification
> https://microsoft.github.io/language-server-protocol/specifications/specification-3-14/
> 
> The JSON RPC implementation might be moved to QtNetwork, instead. I'm
> eager to hear opinions on this. Mind that the JSON RPC protocol
> implementation doesn't depend on any network classes, but only on
> QIODevice. Indeed you can run many existing language servers over stdio.
> 
> Mind also that the language server _protocol_ implementation shown in
> above changes can be used to build both language servers _and_ clients
> for language servers. The basic primitives are automatically generated
> from the specification itself.
> 
> There currently is no good place for the language server code in any
> existing modules. We should not commit it to qtdeclarative, as it would
> be useful for a number of other applications, too:
> 
> It turned out that we need a language server protocol implementation not
> only for the QML language server, but also for the language client in Qt
> Creator. Qt Creator is using its own, manually written, client-only,
> implementation right now. We should strive to maintain only one Qt-based
> language server protocol implementation.
> 
> Another idea is to add rich support for CSS in the style editor of the
> designer by using some existing CSS language server. More generally, we
> could make the integration of existing Qt text editing facilities with
> language support (auto-completion, diagnostics, etc) easier by providing
> a generic language server API.

The repository qt/qtlanguageserver has been created.

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] New repo as playground for potential "serialization" module?

[Kari Oikarinen]

On 6.12.2019 19.36, Arnaud Clère wrote:

> 
> Name: QtDataTransforms ?
> 
> Description:
> QtDataTransforms long-term goal is to make it easy to move data
> to/from specific Qt modules based on a common JSON-like data model
> made of sequences, records, and basic data types. It defines a default
> view of most Qt types following their equivalent QML definitions. It
> is designed to support all of JSON and CBOR formats,
> as well as in-memory data structures like QJsonValue, QCborValue or
> QVariantList/Map. It aims to support more elaborate data models such
> as CSV, XML, and  QAbstractItemModel using optional metadata to allow,
> for instance, reading a CSV file to a TableView in a single line of
> code, writing a TreeView in XML format, etc.
> 
> Responsible persons: me and/or ? Who would be reviewing it?
> Desired repository name: qtdatatransforms ?
> Namespace: QtDataTransforms ? Is it possible to keep a few things in
> Qt namespace ?

Plenty of time has passed and there has been no opposition. However, the
request had a lot of question marks. So I want to verify first.

Is the role of repository clear (to the community) and should I go
forward with creating it?

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] New repo as playground for potential "serialization" module?

[Kari Oikarinen]

On 6.12.2019 19.36, Arnaud Clère wrote:
> Hi,
> 
> Thiago suggested below that I submit my API proposal for serialization
> outside of QtCore to see whether it makes sense.
> I understood it would require a new repo as a playground for a kind of
> "preview" module.
> Should I go on creating a QTQAINFRA issue for that?

You can create a QTQAINFRA ticket, although that will just help in it
not being forgotten by the admins. The decision on creating the new repo
happens here on the mailing list. There is some hope in admins
remembering to create the repository based on just the mailing list
thread.

> See details below.
> 
> Thanks,
> Arnaud
> 
> -- Forwarded message -
> De : Arnaud Clère 
> Date: jeu. 28 nov. 2019 à 13:25
> Subject: Re: [Development] FW: QtCS19 Serialization session
> To: 
> 
> -Original Message-
> From: Thiago Macieira 
>>
>> Would it make sense if this API were not in QtCore?
>> Then we could give it a try and see how many people think it's useful, what 
>> its pitfalls are, etc.
> 
> Yes, it is possible and it perfectly makes sense. It does not have to
> wait for Qt6 too.
> 
> It only implies to duplicate a CBOR stream writer but the new one
> would have the opportunity to distinct QByteArray containing binary
> data from those explicitly containing utf8 data for better
> performance. The existing QCborStreamReader can be used from the
> outside as performance is not so critical for reading.
> 
> At one point, my longer term goal of providing a structured logging
> facility compatible with QDebug could bring back the subject to move a
> few things back to QtCore but maybe not.
> 
> How do I proceed? I guess I need to ask for a specific repo as described here:
> https://wiki.qt.io/Requesting_New_Repositories
> 
> Name: QtDataTransforms ?

That name is pretty abstract and just based on it I would have guessed
in a completely wrong direction what the module is for.

You're talking about it as a serialization module even in the subject of
this mail. Wouldn't QtSerialization be a natural name?

> 
> Description:
> QtDataTransforms long-term goal is to make it easy to move data
> to/from specific Qt modules based on a common JSON-like data model
> made of sequences, records, and basic data types. It defines a default
> view of most Qt types following their equivalent QML definitions. It
> is designed to support all of JSON and CBOR formats,
> as well as in-memory data structures like QJsonValue, QCborValue or
> QVariantList/Map. It aims to support more elaborate data models such
> as CSV, XML, and  QAbstractItemModel using optional metadata to allow,
> for instance, reading a CSV file to a TableView in a single line of
> code, writing a TreeView in XML format, etc.
> 
> Responsible persons: me and/or ? Who would be reviewing it?
> Desired repository name: qtdatatransforms ?
> Namespace: QtDataTransforms ? Is it possible to keep a few things in
> Qt namespace ?

The namespace talked about on the wiki page is not a C++ namespace. It's
the namespace in the repository name on Gerrit. So qt like in qt/qtbase
or playground like in playground/qtjsonstream.

But the right namespace here is a good question. Wiki says:


   - All projects which are meant to ultimately end up in the qt
 distribution should start out in the qt/ namespace.
   - The playground/ namespace is for projects which don't fit any
 other category.


This sounds like it could belong in the qt/ namespace if it aspires to
be an actual Qt module included in releases. Or released separately but
a first-class part of Qt.

If this is supposed to be just a working area for a prototype before
later inclusion for the ultimate product in qtbase, then maybe
playground/ is a better fit. But in that case it could be just a feature
branch in qt/qtbase. I think I got the impression that actual users
getting to see and use this API is the goal. So likely being under qt/
fulfills the purpose better.

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Eliminate soft branching phase from release process

[Kari Oikarinen]

On 15.10.2019 12.35, Oswald Buddenhagen wrote:
 > the gist is that this somewhat complicated downmerge process exists for
 > good reasons. it shifts the "logistical" load of dealing with the
 > branching from every contributor to the few people involved in the
 > branch management.
 >
 > history (now found via browsing archives; it appears impossible to
 > google that message without putting the exact subject in quotes):
 > https://lists.qt-project.org/pipermail/releasing/2014-August/001804.html
 > there appears to be no other public list activity related to this.
 > apparently, everything happened on irc.
 >
 > the previous installment of evolving policy was here:
 > 
https://lists.qt-project.org/pipermail/releasing/2014-February/001618.html
 > (that's essentially what you want to go back to).
 > as you can see from the dates, it took us a single feature release to
 > conclude that another change was necessary.

Thanks a lot for digging these up.

I'll withdraw this proposal. Firstly, because I learned the motivation
for the current approach better during the course of this thread and
thus no longer want to push for the change. And secondly, because a
new branching model discussion is ongoing and the currently most
probable resolution of that will make the whole downmerging step
disappear anyway.

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Notes from "C++17 language and std library features for Qt 6"

[Kari Oikarinen]

I managed to mangle copy pasting to the mail, so probably better to read
from the wiki page rather than read everything twice in a tricky order.

On 20.11.2019 21.20, Kari Oikarinen wrote:
> Hi!
> 
> Here are the notes for the C++17 related session held today at QtCS. I
> tried my best to capture the discussion, but there might still be a lot
> of errors.
> 
> Notes are also in the wiki at
> https://wiki.qt.io/Qt_Contributor_Summit_2019_-_C%2B%2B17_Features_Notes
> 
> # Language
> 
> 
> ## if constexpr
> 
> # Language
> 
> 
> ## if constexpr
> 
> Very useful for our containers.
> 
> 
> ## Fold expressions
> 
> Shortcut for handling parameter packs of vadiadic templates. No need
> to write recursive template helpers.
> 
> 
> ## Inline variable
> 
> Volker: What is the impact of using inline variables to static data
> initialization? How do we deal with `Q_GLOBAL_STATIC`?
> 
> Inline variables are safer than static globals. Compiler and linker
> guarantee that there will be just one definition.
> 
> `Q_GLOBAL_STATIC` still provides lazy initialization. So inline
> variables are not a full replacement. Any big globals that aren't
> necessarily used should be gated by lazy initialization to avoid
> constructing them unnecessarily.
> 
> 
> ## Polymorphic lambdas
> 
> What is it? It has auto as its parameter type. So the same lambda can
> be used with multiple invocations with parameters of different types.
> 
> Most common use is just for brevity. It gives you perfect forwarding
> as well, if you use auto && as the type.
> 
> But these are not API visible, just perhaps useful inside the
> implementation.
> 
> 
> ## Structured bindings
> 
> QRect and QPoint might be possible candidates. But there will not be
> many that this makes sense for.
> 
> Some of these will already be aggregates and work automatically. But
> perhaps they for example have user-defined constructors and so don't
> fulfill the requirements of that.
> 
> 
> ## Language attributes
> 
> There are macros for many standard attributes, like nodiscard,
> deprecated, fallthrough, likely and unlikely.
> 
> When is the right point to remove this macros and use the attributes
> directly? When all compilers support it. Although that causes pain
> when backporting to older branches.
> 
> That applies to all language features, though. Some backporting is
> really hairy, like converting if constexpr solutions back to template
> specializations.
> 
> 
> ## Modules (C++20)
> 
> Properly modularizing Qt is going to be a huge undertaking. There
> should be some prototyping done by an energetic volunteer.
> 
> There are rumors that moc generated code leads to some issues here.
> 
> How will `QT_CONFIG()` macros work together with modules? Every
> permutation would need to be shipped as a separate module. But they
> are going to be constant within a built Qt. Not something the user of
> the library can change.
> 
> Modules are not supported by build systems (including qmake and CMake)
> yet. CMake developer Kitware is working on it, though.
> 
> 
> ## Coroutines (C++20)
> 
> QDialog::call/exec() are already coroutines, but stackful ones. So
> converting to them stackless is not really possible. But there might
> be better candidates in networking or elsewhere with callbacks.
> 
> Standard coroutines are quite cumbersome to use. Would we use an
> external helper library with that or would Qt provide their own helper
> for coroutines? Having Qt-friendly coroutine helpers would be nice.
> 
> Test data supplying is currently a huge matrix of QVariants and is
> actually a performance bottleneck for our tests. Using generators for
> these might be helpful? They are not going to make a difference
> compared to a good hand-written generator. So the performance issues
> might be fixed with other approaches.
> 
> 
> # Library
> 
> Contributions to any of these would be welcome.
> 
> 
> ## std::any
> 
> std::any is like a QVariant that does not need registration.
> 
> Could there be conversions between QVariant and std::any? Ville is
> skeptical about how to do that. Olivier suggested adding support for
> conversion from std::any to QVariant into QMetatype. But can that be
> done with just a reference to `std::type_info`?
> 
> std::any is a replacement for void\*. It knows the type that it holds.
> 
> 
> ## std::filesystem
> 
> Giuseppe: Should be use std::filesystem::path types consistently in
> our APIs instead of QString? Ville: There should be a prototype patch
> to see how big the effect is. I'm concerned that the impact would be
> too big.
> 
> Is std::

[Development] Notes from "C++17 language and std library features for Qt 6"

[Kari Oikarinen]

Hi!

Here are the notes for the C++17 related session held today at QtCS. I
tried my best to capture the discussion, but there might still be a lot
of errors.

Notes are also in the wiki at 
https://wiki.qt.io/Qt_Contributor_Summit_2019_-_C%2B%2B17_Features_Notes

# Language


## if constexpr

# Language


## if constexpr

Very useful for our containers.


## Fold expressions

Shortcut for handling parameter packs of vadiadic templates. No need
to write recursive template helpers.


## Inline variable

Volker: What is the impact of using inline variables to static data
initialization? How do we deal with `Q_GLOBAL_STATIC`?

Inline variables are safer than static globals. Compiler and linker
guarantee that there will be just one definition.

`Q_GLOBAL_STATIC` still provides lazy initialization. So inline
variables are not a full replacement. Any big globals that aren't
necessarily used should be gated by lazy initialization to avoid
constructing them unnecessarily.


## Polymorphic lambdas

What is it? It has auto as its parameter type. So the same lambda can
be used with multiple invocations with parameters of different types.

Most common use is just for brevity. It gives you perfect forwarding
as well, if you use auto && as the type.

But these are not API visible, just perhaps useful inside the
implementation.


## Structured bindings

QRect and QPoint might be possible candidates. But there will not be
many that this makes sense for.

Some of these will already be aggregates and work automatically. But
perhaps they for example have user-defined constructors and so don't
fulfill the requirements of that.


## Language attributes

There are macros for many standard attributes, like nodiscard,
deprecated, fallthrough, likely and unlikely.

When is the right point to remove this macros and use the attributes
directly? When all compilers support it. Although that causes pain
when backporting to older branches.

That applies to all language features, though. Some backporting is
really hairy, like converting if constexpr solutions back to template
specializations.


## Modules (C++20)

Properly modularizing Qt is going to be a huge undertaking. There
should be some prototyping done by an energetic volunteer.

There are rumors that moc generated code leads to some issues here.

How will `QT_CONFIG()` macros work together with modules? Every
permutation would need to be shipped as a separate module. But they
are going to be constant within a built Qt. Not something the user of
the library can change.

Modules are not supported by build systems (including qmake and CMake)
yet. CMake developer Kitware is working on it, though.


## Coroutines (C++20)

QDialog::call/exec() are already coroutines, but stackful ones. So
converting to them stackless is not really possible. But there might
be better candidates in networking or elsewhere with callbacks.

Standard coroutines are quite cumbersome to use. Would we use an
external helper library with that or would Qt provide their own helper
for coroutines? Having Qt-friendly coroutine helpers would be nice.

Test data supplying is currently a huge matrix of QVariants and is
actually a performance bottleneck for our tests. Using generators for
these might be helpful? They are not going to make a difference
compared to a good hand-written generator. So the performance issues
might be fixed with other approaches.


# Library

Contributions to any of these would be welcome.


## std::any

std::any is like a QVariant that does not need registration.

Could there be conversions between QVariant and std::any? Ville is
skeptical about how to do that. Olivier suggested adding support for
conversion from std::any to QVariant into QMetatype. But can that be
done with just a reference to `std::type_info`?

std::any is a replacement for void\*. It knows the type that it holds.


## std::filesystem

Giuseppe: Should be use std::filesystem::path types consistently in
our APIs instead of QString? Ville: There should be a prototype patch
to see how big the effect is. I'm concerned that the impact would be
too big.

Is std::filesystem::path API stable enough? Standard committee cares
about API stability a lot, so that's not a worry. Although some want a
new version of the API that uses std::expected.


## Parallel STL algorithms

We could allow parallel execution tags in our API to let users ask for
use of parallel algorithms.

But what are the places in Qt API that actually need these? More data
analysis stuff (if developed) would find it helpful. But often users
get to choose their own algorithms and so can use parallel algorithms
without our containers needing to know about it.

If a parallel STL implementation is not available, falling back to
single-threaded implementation is always an option. So support could
be utilized only when available and not demanded from all platforms.
Or the platfrom support can be a shim that still always processes
everything without parallelism.


## 

Re: [Development] Two-digit dates: what century should we use ?

[Kari Oikarinen]

On 5.11.2019 15.44, Edward Welbourne wrote:> Hi all,
 >
 > Prompted by [0], I'm looking at what century to use for years, when the
 > text being read is expected to be in a "short format" that only includes
 > two digits.
 > * [0] https://bugreports.qt.io/browse/QTBUG-74323
 >
 > tl;dr - how do folk feel about (in Qt 6) a century-wide window, ending a
 > decade or three ahead of QDate::currentDate(), and placing any two-digit
 > year in that range ?
 >
 > Before anyone says "Don't Do That" (or "why would anyone use two-digit
 > years after the mess of y2k ?"), bear in mind that CLDR (the Unicode
 > consortium's common locale data repository, on which QLocale's data is
 > based) provides short date formats, many of which use two-digit years.
 >
 > We currently fail to round-trip dates via such formats because 1900 is
 > used as default year when no year is specified and (thus) 19 is used as
 > default century number when only the later digits are (understood to be)
 > specified.  As we get further into the twenty-hundreds (as it were), this
 > shall grow to be an increasing jarring flaw in date format handling.

I think even in the future many two-digit year formatted dates will
refer to 19xx (either because they are old or because that's the
assumption widely). So correct handling of those formats will be
impossible anyway. They don't contain enough information. But it's of
course unfortunate if the dates you stored yourself can't be read back
correctly.

 > I'm considering changing that: since it's a material behaviour change,
 > it clearly needs to happen as part of Qt 6, which at least gives me a
 > few months to discuss it and see what folk think is a better plan than
 > what we have.
 >
 > It's notable that ECMAScript's Date constructor adds 1900 to any year
 > number from 0 through 99 (even if supplied as one of a sequence of
 > integer arguments, not a string), causing problems for the
 > representation of dates from 1 BCE through 99 CE.  (I must remember to
 > tease my friend on the ECMA 262 committee about that - his excuse will
 > be that it was copied from an early version of Java, I suspect - and see
 > if he can coax them into changing it.)  Likewise, C's struct tm (used by
 > mktime and friends) has a 1900 offset on its year number: that's
 > probably never going to change, perverse as it is and shall increasingly
 > be.

Surely that's not a comprehensive list. I don't expect either of these
to change and staying in line with other software can avoid surprises.

I thought almost everyone would assume 1900-1999 as the range.
Apparently that's not true though. Python uses the range 1969-2068 and
C# depends on locale but appears to at least sometimes be 1930-2029.
Using two-digit years is a much worse idea than I thought since there
doesn't seem to be consensus.

 > Folk still talk about "The fifties" and mean the 1950s; probably
 > likewise the forties, thirties and even twenties.  That last, at least,
 > shall soon be something of a problem.  Folk can see more of the past
 > than of the future, so perhaps it's not much of a surprise that common
 > nomenclature reserves short phrases for the past at the expense of the
 > future: "The sixties" shall be in the past for a few decades yet, I
 > think.  So rather than having a default century, and maybe changing it
 > abruptly to 20 at some point in the next fifty years, I think it would
 > be better to have two-digit years coerced into a century-wide window
 > about the (forever moving) present.
 >
 > Perhaps we should make that a narrower window and treat roughly a decade
 > near the wrap-around as error - e.g. using 1945--2035 as our year range,
 > with two-digit years 36 through 44 treated as undecodable.
 >
 > The question then arises: what year-range should we use ?
 >
 > Two things I'm fairly sure should be true are:
 > * the current year (i.e. QDate::currentDate().year(), naturally) should
 >be included in the range;

I don't think it's that obvious. Many systems start at the UNIX epoch
and then may get the current time from network later. That might
result in the year-range changing during application lifetime, which
sounds horrible. You wouldn't know what certain input results into
when reasoning statically.

 > * the range should be contiguous.
 >
 > So the interesting questions are:
 > * how far into the past and future should the range reach ?
 > * how wide a buffer (if any) should we leave ?
 >
 > If we don't have a buffer, my inclination is to put the transition date
 > at a decade boundary, e.g. 49 -> 2049 but 50 -> 1950, as this shall feel
 > less perverse to most folk than having a mid-decade transition such as
 > 44 -> 2044 but 45 -> 1945.  However, with a buffer, this problem goes
 > away, as there aren't adjacent two-digit numbers that map to wildly
 > different years; instead, the intervening numbers that aren't handled
 > make the discontinuity seem more sensible.  In principle a one year
 > buffer would suffice, but 

Re: [Development] Proposal: Eliminate soft branching phase from release process

[Kari Oikarinen]

On 15.10.2019 11.19, Oswald Buddenhagen wrote:
> On Tue, Oct 15, 2019 at 06:16:33AM +0000, Kari Oikarinen wrote:
>> After thinking about it again, I agree with you that it's irrelevant.
>> There could be a category of changes that would need to wait and I was
>> describing it.
>>
>> But in fact there isn't, since the branching and the associated cut-off
>> has not happened yet during soft branching. So any changes that need to
>> happen before the cut-off can target the old branch. Either they make
>> the cut-off (are included in the downmerge) or they don't and are
>> included in the next release.
>>
>> The period is in fact exactly the same as the week before hard branching
>> would be in my proposal.
>>
> yep. i take that as an official retraction of the proposal. ^^

It isn't, it was just to retract this part of my reply. I think the
other aspects are still worth discussing.

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Eliminate soft branching phase from release process

[Kari Oikarinen]

On 14.10.2019 16.40, Kari Oikarinen wrote:
> 
> 
> On 12.10.2019 14.14, Oswald Buddenhagen wrote:
>   > On Fri, Oct 11, 2019 at 12:04:20PM +, Kari Oikarinen wrote:
>   >
>   >> Currently there is a bit of uncertainty about when exactly the
>   >> downmerges happen,
>   >>
>   > yes, and that's entirely fine. the whole *point* of the process is to
>   > make it irrelevant when it happens. if you rely on the time of the
>   > downmerge but are not a release manager, you're doing it wrong.
> 
> It's not irrelevant! People who target the newly created branch should
> not wait until the last minute to retarget and thus the exact point in
> time does not matter to them.
> 
> But anyone who wants to *actually* target the old branch needs to wait
> for the downmerge to pass. In effect the week of soft branching means
> that the old branch is temporarily closed, because the changes staged
> to it actually go to the newly created branch. The problem is that to
> know whether that is the case you need to either read Jani's mails or
> check the history for the downmerge. (And even if you did check, are
> you sure it's final?)

After thinking about it again, I agree with you that it's irrelevant.
There could be a category of changes that would need to wait and I was
describing it.

But in fact there isn't, since the branching and the associated cut-off
has not happened yet during soft branching. So any changes that need to
happen before the cut-off can target the old branch. Either they make
the cut-off (are included in the downmerge) or they don't and are
included in the next release.

The period is in fact exactly the same as the week before hard branching
would be in my proposal.

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Eliminate soft branching phase from release process

[Kari Oikarinen]

On 12.10.2019 14.14, Oswald Buddenhagen wrote:
 > On Fri, Oct 11, 2019 at 12:04:20PM +0000, Kari Oikarinen wrote:
 >> I want to propose eliminating soft branching phase and instead use the
 >> creation of the branch as a cut-off for feature freeze (or bug fixes
 >> for a patch release).
 >>
 > (facepalm)
 >
 > but in case you actually tried to do your homework first ... well i'm
 > failing to find the old mails myself. something is rather b0rked with
 > the mail archive indexing; google and duckduckgo produce mostly hits to
 > the mbox files.

I did try to see if there was something about the reasons and asked
around a little. Thanks for bringing up original rationale.

 >
 >> As far as I can tell, the major motivation for providing this week of
 >> soft branching is to allow people to finish their last changes without
 >> needing to retarget the change to a new branch.
 >>
 > no, it's not.
 > the reason is that the huge CI delay makes it impractical to know
 > whether a change will still land in time for branch creation. also,
 > people just don't pay attention to the branching announcements in real
 > time.
 > so the alternatives to soft branching are a) restricting the source
 > branch before branching (which is obviously counterproductive) or b)
 > accepting the need for a significant number of cherry-picks (which are a
 > hassle to make, and an annoyance in the resulting git history).

What I'm thinking of is on the b) side of things. But I'm not sure why
the amount of cherry-picks would be a "significant number"?

When branching out a minor branch, new features that miss the
branching deadline miss the feature freeze. They don't need to be
cherry-picked. Wouldn't the category of bug fixes that are not
appropriate to the older stable branch but should happen in a feature
freezed branch be pretty narrow as well?

When branching out a release branch, only fixes to release blockers
should be cherry-picked. Everything else also missed a deadline and
appropriately belongs to the next release.

The window of time there is to make these mistakes varies, since it
starts from the branching happening and ends when there is somebody in
an open review that realizes the change should target the newly
created branch instead. That should be pretty short for people that
regularly read the development list, which of course isn't everyone.

The combination of restrictions in categories and time means that it
seems to me there shouldn't be that many commits to cherry-pick. What
type of commits that would need that handling do you expect a lot of?

 >
 >> Currently there is a bit of uncertainty about when exactly the
 >> downmerges happen,
 >>
 > yes, and that's entirely fine. the whole *point* of the process is to
 > make it irrelevant when it happens. if you rely on the time of the
 > downmerge but are not a release manager, you're doing it wrong.

It's not irrelevant! People who target the newly created branch should
not wait until the last minute to retarget and thus the exact point in
time does not matter to them.

But anyone who wants to *actually* target the old branch needs to wait
for the downmerge to pass. In effect the week of soft branching means
that the old branch is temporarily closed, because the changes staged
to it actually go to the newly created branch. The problem is that to
know whether that is the case you need to either read Jani's mails or
check the history for the downmerge. (And even if you did check, are
you sure it's final?)

 >
 >> since it requires not only someone to do it, but
 >> also CI not being active in the target branch. That's a requirement
 >> because downmerges (if they have no conflicts) are pushed directly to
 >> the repositories instead of going through regular CI. Eliminating them
 >> also eliminates this irregularity.
 >
 >> It hasn't been a big problem,
 >>
 > yes, exactly.
 >
 > but if you wanted to get rid of the direct pushes, the forward merge bot
 > (which is rather automated at that point, unlike back in the day) could
 > be easily extended to push and stage the downmerges as well.

Worth thinking about. But I'd probably lean towards continuing as
before if this proposal isn't accepted. Because they aren't a big
problem. I just thought getting rid of them would be a bonus.

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Proposal: Eliminate soft branching phase from release process

[Kari Oikarinen]

I want to propose eliminating soft branching phase and instead use the
creation of the branch as a cut-off for feature freeze (or bug fixes
for a patch release). Frederik already alluded that there has been
some discussion about making this change in the email about the final
downmerge to 5.13.2.

Right now a week before feature freeze the new branch is created and
the release manager sends a heads-up mail that tells people to finish
their changes within a week or retarget them to the new branch. Then
after the week is up the original branch is merged into the new
branch. This is called a "downmerge", since it is in the opposite
direction compared to the usual merges that go "up" to newer releases.
Once the downmerge is done, branching is considered complete and
feature freeze is in effect.

Similar week of soft branching is also involved when patch level
branches are created.

As far as I can tell, the major motivation for providing this week of
soft branching is to allow people to finish their last changes without
needing to retarget the change to a new branch. Retargeting of a large
number of changes would also have provided a large amount of work to
Gerrit admins, since on our old Gerrit retargeting the change needed
admin rights. And of course admin response time would have served as a
bottleneck to work.

Nowadays everyone can however move their own changes over to a new
branch. So as our tools have improved, I see a chance to simplify our
processes as well.

So instead of the soft branching process I propose the following:

- A week before feature freeze date release manager sends a reminder
   email about it. This provides the same useful warning as the
   initiation of soft branching has so far.

- On feature freeze day release team creates the new branch. They send
   an email to development list informing people about the feature
   freeze being in effect.

- If your change did not make it into dev before the new branch was
   created, it did not make the feature freeze cut. If it is a bug fix
   that should go to the next release still, you need to move it to the
   new branch. If the change happened to be integrated after branch
   creation but before you noticed, you need to cherry-pick it to the
   new branch. But that should hopefully be an exception.

- There are no more downmerges. All merges happen in the same
   direction. Hopefully that makes how they happen easier to
   understand.

The same approach should be used for patch level branches as well.

Currently there is a bit of uncertainty about when exactly the
downmerges happen, since it requires not only someone to do it, but
also CI not being active in the target branch. That's a requirement
because downmerges (if they have no conflicts) are pushed directly to
the repositories instead of going through regular CI. Eliminating them
also eliminates this irregularity. It hasn't been a big problem, but
these commits have no corresponding Gerrit changes, which has confused
people when they can't actually find the review because there wasn't
one. It can also result in broken state of code, although only rarely.
By getting rid of downmerges we eliminate the vast majority of direct
pushes (and all regularly done ones).

Since branches can be created without waiting for idle CI, the timing
of feature freeze coming into effect could become better known in
advance. This helps in avoiding confusion about whether it's in effect
or not.

If this is approved, I promise to edit QUIP-11 [1] to match.

[1]: https://codereview.qt-project.org/c/meta/quips/+/228450 -
  Hopefully it will be merged at some point...

--
Kari

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

Re: [Development] Merging wip/qt6 to dev

[Kari Oikarinen]

Hi!

wip/qt6 branch has been closed. Like Simon said, please retarget or
abandon your changes that target that branch.

You can move your change to target a different branch on the change page
in Gerrit. From the upper right corner click the three dots and then
"Move change".

On 10/11/19 12:55 PM, Simon Hausmann wrote:
> Hi,
> 
> Finally all changes from wip/qt6 have been merged into dev for all 
> modules. I've filed QTQAINFRA-3273 for the Gerrit admins to close the 
> branch. There are still open pending changes in some repos, please take 
> a look at
> 
> https://codereview.qt-project.org/q/owner:self+branch:wip/qt6+status:open
> 
> to see if you have any pending changes that need to be re-targeted or 
> abandoned.
> 
> The dependencies.yaml propagation is almost through, webengine and 
> webview are pending.
> 
> Simon
> 
> *From:* Simon Hausmann 
> *Sent:* Wednesday, October 2, 2019 15:57
> *To:* Qt development mailing list 
> *Subject:* Re: [Development] Merging wip/qt6 to dev
> Hi,
> 
> Here's a new update on the merge of wip/qt6 to dev:
> 
> The culprit that broke the Windows 7 tests has been identified, a fix 
> (revert) merged into qtbase 5.15 and merged up to dev. Unfortunately 
> qtdeclarative is still failling because for declarative the CI 
> configuration adds developer-build enabled tests on armv7 and armv8 -- 
> to cover issues we've had in the past in the JIT on these platforms. 
> That configuration will make the CI implicitly also run tests in qtbase 
> for armv7/armv8 with -developer-build and those are failing suddenly 
> (qtextmarkdownwriter).
> 
> 
> 
> Simon
> 
> *From:* Simon Hausmann 
> *Sent:* Thursday, September 26, 2019 13:07
> *To:* Qt development mailing list 
> *Subject:* Re: [Development] Merging wip/qt6 to dev
> Hi,
> 
> Brief update on the status of the merge:
> 
> After qtbase, the direct leaf modules such as qtsvg, qtimageformats, 
> etc. were merged. What's left is qtdeclarative and everything that 
> depends on it. While the actual merge of wip/qt6 went through for 
> qtdeclarative, the combination of current dev qtbase and declarative 
> produce several failing tests on Windows 7. This is tracked 
> in QTBUG-78742 and I haven't found out yet what change in qtbase causes 
> the failures on Windows ;(. Initially I thought of excluding just the 
> one failing test, but as there are several failing tests this indicates 
> that something is quite broken.
> 
> 
> Simon
> 
> *From:* Simon Hausmann 
> *Sent:* Wednesday, September 18, 2019 11:47
> *To:* Lars Knoll 
> *Cc:* Qt development mailing list 
> *Subject:* Re: [Development] Merging wip/qt6 to dev
> Hi,
> 
> Okay, qt5's dev branch has now a slightly reduced configuration set and 
> qtbase wip/qt6 was merged to dev. So qtbase dev now has QT_VERSION set 
> to 6.0.0.
> 
>  From this point on, I'll try to drive the merges and updates of the 
> remaining modules using the new module pinning.
> 
> Simon
> 
> *From:* Lars Knoll 
> *Sent:* Tuesday, September 17, 2019 10:03
> *To:* Simon Hausmann 
> *Cc:* Qt development mailing list 
> *Subject:* Re: [Development] Merging wip/qt6 to dev
> I’d say yes, let’s merge those into dev as well. Those are all platforms 
> we don’t want to support in Qt 6.0. (tvOS, watchOS and Integrity might 
> come back at some point).
> 
> Cheers,
> Lars
> 
>> On 17 Sep 2019, at 09:56, Simon Hausmann > > wrote:
>>
>>
>> I'm leaning towards the same.
>>
>> Regarding the overall merge, there is one other change that needs to 
>> happen before we can have a chance at building qtbase:
>>
>> In the wip/qt6 branch in 
>> commit 5677a43a25a9dc1a3151e6b28cbf9fe015a1aff4 in qt5.git, various 
>> platforms and configurations were removed from the CI:
>>
>>     * MSVC2015
>>     * Some MSVC 2017 configurations
>>     * macOS 10.12, macOS 10.13
>>     * TvOS, WatchOS
>>     * Integrity
>>
>>
>> What shall we do about this? Merge the reduction also into dev?
>>
>>
>> Simon
>> 
>> *From:*Lars Knoll mailto:lars.kn...@qt.io>>
>> *Sent:*Tuesday, September 17, 2019 9:15
>> *To:*Simon Hausmann mailto:simon.hausm...@qt.io>>
>> *Cc:*Qt development mailing list > >
>> *Subject:*Re: [Development] Merging wip/qt6 to dev
>> Hi,
>>
>> Great to get the wip/qt6 branches merged back into dev. I’d simply try 
>> to take the dependencies.yaml into use at the same time instead of 
>> having to work around the CI.
>>
>> Cheers,
>> Lars
>>
>>> On 17 Sep 2019, at 09:05, Simon Hausmann >> > wrote:
>>>
>>> Hi,
>>>
>>> Now that the Qt 5.15 branches exist and dev is intended to become Qt 
>>> 

Re: [Development] Updating/changing "default" branch for qtbase repository

[Kari Oikarinen]

On 16.9.2019 15.10, Lars Knoll wrote:
> 
>> On 16 Sep 2019, at 13:26, Albert Astals Cid via Development 
>> mailto:development@qt-project.org>> wrote:
>>
>> El dilluns, 16 de setembre de 2019, a les 13:22:22 CEST, Frederik Gladhorn va
>> escriure:
>>> On mandag 16. september 2019 12:22:06 CEST Edward Welbourne wrote:
 Albert Astals Cid (16 September 2019 11:33) wrote:
> If i do
>
>  git clone ssh://myu...@codereview.qt-project.org/qt/qtbase
>
> I get branch 5.12
>
> Given that 5.12 is now on cherry-pick mode (AFAIK) would it make more
> sense to default to branch 5.13?

 We have a history of setting a release branch (stable, I think; perhaps
 LTS) as the default branch in our repositories.  This means that anyone
 who mirrors our repositories gets that as their default branch (unless /
 until they update it).  I don't see this as a good choice: getting dev
 on the branches that have it would make more sense.

 IIUC, the rationale for the present practice is that we want to make it
 easier for folk who send us fixes.  I honestly doubt we'd suffer harm by
 having fixes sent to us on dev a bit more often (and other changes, that
 *do* belong on dev, being sent first to another branch would surely
 happen less often); reviewers can surely help the contributor get it
 onto the right branch, if there's a good reason why dev isn't good
 enough.

 ... now, where have I met this discussion recently ?
 I'm quite sure I have, but can't remember where ...
>>>
>>> I also had a chat about this recently and the Gerrit admins in general don't
>>> really fell like constantly changing the default branch, so I'd be much in
>>> favor of just moving all default branches to dev.
>>
>> Same here, i think dev makes sense too, but didn't want to propose something
>> so radical myself ^_^
> 
> +1 for having it pointing to dev and never changing it again. It’s also more 
> in 
> line with most other git repos out there :)

There doesn't seem to be opposition to this. Any single choice also can't always
be correct, because the right branch to target depends on what kind of change
you are working on.

I've gone ahead and changed the default branches to be dev.

-- 
Kari

> 
> Cheers,
> Lars
> 
>>
>> Cheers,
>>  Albert
>>
>>>
>>> In my opinion we should mostly care about the dev branch, since that's where
>>> all future development needs to happen. Moving changes back into older
>>> releases can of course be important, but that's not what most people should
>>> have to worry about.
>>>
>>> Cheers,
>>> Frederik
>>>
 Eddy.

 ___
 Development mailing list
 Development@qt-project.org 
 https://lists.qt-project.org/listinfo/development
>>
>>
>> --
>> Albert Astals Cid |albert.astals@kdab.com 
>> | Senior Software Engineer
>> Klarälvdalens Datakonsult AB, a KDAB Group company
>> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
>> KDAB - The Qt, C++ and OpenGL Experts
>>
>> ___
>> Development mailing list
>> Development@qt-project.org 
>> https://lists.qt-project.org/listinfo/development
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
> 

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

Re: [Development] [Gerrit-admin] Cherry-pick mode for 5.12

[Kari Oikarinen]

On 2.9.2019 16.27, Edward Welbourne wrote:
> On 2.9.2019 15.23, Lars Knoll wrote:
>>> According to QUIP-5
>>> (http://quips-qt-io.herokuapp.com/quip-0005.html), we should move the
>>> 5.12 branch into cherry-pick mode now that we have created the 5.14
>>> branch.
>>>
>>> Gerrit admins, could you please do the required changes in gerrit and
>>> for the sanity bot? Let’s do one final down-merge of 5.12 to 5.13
>>> once that’s done.
> 
> Kari Oikarinen (2 September 2019 15:13) replied:
>> Sanity bot should now recognize 5.12 as an LTS branch and not complain
>> about cherry-picks there.
> 
> ... and complain about non-cherry-picks there.
> (It's just done so to me, for a change that was already underway.)
> 
>   Eddy.
> 

True, it's an awkward transition period. But you can of course override the
bot's verdict. As long as the change gets in before the final merge.

As soon as the risk of missing the merge is high, the bot is actually right and
it's better to retarget to 5.13.

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Gerrit-admin] Cherry-pick mode for 5.12

[Kari Oikarinen]

On 2.9.2019 15.23, Lars Knoll wrote:
> Hi all,
> 
> According to QUIP-5 (http://quips-qt-io.herokuapp.com/quip-0005.html), we 
> should move the 5.12 branch into cherry-pick mode now that we have created 
> the 5.14 branch.
> 
> Gerrit admins, could you please do the required changes in gerrit and for the 
> sanity bot? Let’s do one final down-merge of 5.12 to 5.13 once that’s done.
> 

Sanity bot should now recognize 5.12 as an LTS branch and not complain about
cherry-picks there.

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Moving to Gerrit 2.16.9

[Kari Oikarinen]

On 2.7.2019 15.13, Kari Oikarinen wrote:
> 
> On 2.7.2019 14.59, Cristian Adam wrote:
>>> -Original Message-
>>> From: Development  On Behalf Of
>>> Frederik Gladhorn
>>> Sent: Thursday, 27 June 2019 16:11
>>> To: Qt Project Development Mailing-List 
>>> Subject: [Development] Moving to Gerrit 2.16.9
>>>
>>> Hi,
>>>
>>> Just to keep the ball rolling, we prepared the upgrade to move from Gerrit
>>> 2.16.7 to 2.16.9. I don't expect any real changes, but it's a good exercise 
>>> for us
>>> to stay up to date and see if the scripting of the upgrade works.
>>> The only real challenge was upgrading Bazel, since every Gerrit version
>>> seems to only compile with one exact Bazel version (roughly).
>>>
>>> So far it seems to work nicely for me, running the script which stops 
>>> gerrit,
>>> pushes the new release and restarts it takes around two minutes, so there
>>> won't be any significant downtime this time around.
>>>
>>> Assuming there are no big concerns I'll just do the upgrade tomorrow, on the
>>> test instance it works without problems.
>>>
>>> On a related note, now that things are generally working with the new 
>>> Gerrit,
>>> I was wondering if we want to consider plugins. There is one to add
>>> reviewers based on git blame https://gerrit-
>>> review.googlesource.com/admin/repos/plugins/reviewers-by-blame
>>> and I'll give Gravatar a spin:
>>> https://gerrit-review.googlesource.com/admin/repos/plugins/avatars-
>>> gravatar
>>>
>>> We should also consider the various webhooks plugins. Comments
>>> appreciated.
>>>
>>> Cheers,
>>> Frederik
>>>
>>
>> Hi,
>>
>> I'm getting from Qt Sanity Bot for 
>> https://codereview.qt-project.org/c/qt-creator/qt-creator/+/266791
>>
>> The following reply every 5 minutes:
>>
>>  Worker 'sanity' produced an unreasonable amount of output. You should 
>> ask the bot maintainers for advice.
>>
>> The current behavior is a bit loopy, can we do something about it?
> 
> I guess you've managed to get sanity into a situation where it doesn't give a
> sanity score at all.
> 
> Then once the bot looks at the commits it hasn't scored yet, it will repeat 
> that
> again and again.

This isn't actually sufficient to cause the issue, the bot remembers what
commits it has looked at during current run and doesn't look at them again.

So the new attempts only happen when sanity bot is started again and it looks at
all open changes it hasn't reviewed yet.

But looks like for some reason sanity bot's connection (with which it receives
notifications about new patchsets) drops every 5 minutes and causes the bot to
quit. When it is automatically restarted, it then tries to review again because
of missing review.

I manually put a negative review in place, so at least the spam should be over
for this specific commit for now.

> Could you run sanity bot locally and see what is happening to it? There is a 
> git
> hook in qtrepotools to do it when you commit.
> 

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Moving to Gerrit 2.16.9

[Kari Oikarinen]

On 2.7.2019 14.59, Cristian Adam wrote:
>> -Original Message-
>> From: Development  On Behalf Of
>> Frederik Gladhorn
>> Sent: Thursday, 27 June 2019 16:11
>> To: Qt Project Development Mailing-List 
>> Subject: [Development] Moving to Gerrit 2.16.9
>>
>> Hi,
>>
>> Just to keep the ball rolling, we prepared the upgrade to move from Gerrit
>> 2.16.7 to 2.16.9. I don't expect any real changes, but it's a good exercise 
>> for us
>> to stay up to date and see if the scripting of the upgrade works.
>> The only real challenge was upgrading Bazel, since every Gerrit version
>> seems to only compile with one exact Bazel version (roughly).
>>
>> So far it seems to work nicely for me, running the script which stops gerrit,
>> pushes the new release and restarts it takes around two minutes, so there
>> won't be any significant downtime this time around.
>>
>> Assuming there are no big concerns I'll just do the upgrade tomorrow, on the
>> test instance it works without problems.
>>
>> On a related note, now that things are generally working with the new Gerrit,
>> I was wondering if we want to consider plugins. There is one to add
>> reviewers based on git blame https://gerrit-
>> review.googlesource.com/admin/repos/plugins/reviewers-by-blame
>> and I'll give Gravatar a spin:
>> https://gerrit-review.googlesource.com/admin/repos/plugins/avatars-
>> gravatar
>>
>> We should also consider the various webhooks plugins. Comments
>> appreciated.
>>
>> Cheers,
>> Frederik
>>
> 
> Hi,
> 
> I'm getting from Qt Sanity Bot for 
> https://codereview.qt-project.org/c/qt-creator/qt-creator/+/266791
> 
> The following reply every 5 minutes:
> 
>  Worker 'sanity' produced an unreasonable amount of output. You should 
> ask the bot maintainers for advice.
> 
> The current behavior is a bit loopy, can we do something about it?

I guess you've managed to get sanity into a situation where it doesn't give a
sanity score at all.

Then once the bot looks at the commits it hasn't scored yet, it will repeat that
again and again.

Could you run sanity bot locally and see what is happening to it? There is a git
hook in qtrepotools to do it when you commit.

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Moving to Gerrit 2.16.9

[Kari Oikarinen]

On 27.6.2019 17.53, Tor Arne Vestbø wrote:
> 
> 
>> On 27 Jun 2019, at 16:10, Frederik Gladhorn  wrote:
>>
>> On a related note, now that things are generally working with the new Gerrit,
>> I was wondering if we want to consider plugins. There is one to add reviewers
>> based on git blame
>> https://gerrit-review.googlesource.com/admin/repos/plugins/reviewers-by-blame
> 
> YES

While this sounds good in principle, I'm a little apprehensive about the
details. The plugin adds reviewers on new patchsets. I think that means that if
it adds someone that doesn't actually want to do the review and they delete
themselves, any new patchset is likely to add them again.

I think it might not also recognize WIP status (although it can be configured to
ignore changes with a certain regex in subject).

If it were a button to add automatically suggested reviewers, I'd be in favor.
But I think this particular plugin might be too aggressive. For example Ossi is
likely to be added to quite a few commits touching qmake...

> 
>> and I'll give Gravatar a spin:
>> https://gerrit-review.googlesource.com/admin/repos/plugins/avatars-gravatar
> 
> YES
> 
>>
>> We should also consider the various webhooks plugins. Comments appreciated.
> 
> YES, the core webhook one


-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Jukka Jokiniva as approver

[Kari Oikarinen]

On 27.6.2019 10.25, Frederik Gladhorn wrote:
> Hi all,
> 
> I'd like to nominate Jukka Jokiniva as approver for the Qt Project. Jukka has
> been less visible in the past, since he was mostly involved with
> infrastructure before, but he made the Gerrit upgrade happen and he is now
> active as release manager, next to Jani.
> His focus is on the embedded and automotive releases.
> 
> Here is his list of contributions:
> https://codereview.qt-project.org/q/owner:jukka.jokiniva%2540qt.io
> And reviews:
> https://codereview.qt-project.org/q/reviewer:jukka.jokiniva%2540qt.io

+1

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Gerrit Upgrade

[Kari Oikarinen]

On 25.6.2019 17.07, James McDonnell wrote:
> Is HTTPS access still supposed to work?
> 
> git push gerrit HEAD:refs/for/5.12
> fatal: https://jmcdonn...@codereview.qt-project.org/p/qt/qtbase/info/refs not 
> valid: is this a git repository?
> 
> Did the paths change?

Yes, it's still supposed to work. It also worked for me when testing now. But it
looks like paths have indeed changed and it's now "a" instead of "p"
unfortunately. You will have to update your remotes.

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Gitlab at qt.io

[Kari Oikarinen]

On 9.4.2019 17.02, Richard Weickelt wrote:
> Hi,
> 
> I would like to know more about https://git.qt.io
> 
> - What's the purpose and the future plan?

It's an internal Gitlab instance for The Qt Company. It's mostly a place for
people to put small things that don't belong anywhere in Gerrit and are not
worth creating a repo there. (Or not yet in the case of personal prototypes.)

> - Is it available to registered users at qt.io ? I couldn't log in.

It's not available to external people.

> - Is it connected to gerrit or can it be connected?

No. Big enough projects (even internal ones) get Gerrit repositories.

> - Does it offer gitlab CI?

Since its company-internal, the answer likely doesn't matter to you. But it
doesn't have CI. If a repository is worth having CI for, it should go to Gerrit.

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Gerrit-admin] Shadertools repo request and some words about state of graphics

[Kari Oikarinen]

uarantees 
>> can be given.
>> BTW, (slightly outdated) sets of the generated documentation of qtrhi and 
>> qtshadertools are available 
>> athttps://alpqr.github.io/qtrhi/qtrhi-index.html#andhttps://alpqr.github.io/qtshadertools/qtshadertools-index.html#
>> 2. The shader conditioning tools will not be taken into Qt 5.x, as explained 
>> above. When it comes to the Qt Quick scenegraph's built-in materials 
>> (QSGVertexColorMaterial and friends), they will come with the necessary 
>> pre-processed shaders so this is not a problem for typical Quick items. 
>> Developers wishing to experiment with ShaderEffects or custom QSGMaterials 
>> on 
>> top of the RHI will need to check out and build this module themselves for 
>> now.
>> 3. The Qt Quick port will move to the wip/scenegraphng branch of 
>> qtdeclarative 
>> soon, from there we can merge to dev eventually. For now this still lives 
>> athttps://git.qt.io/laagocs/qtgreyhound(and is heavily work in progress).
>> Unlike earlier attempts, such as the D3D12 backend introduced in Qt 5.8, the 
>> RHI port is not merely a new scenegraph backend (plugin) - rather, it is the 
>> fully featured, default OpenGL rendering path that is getting extended and 
>> massaged into being able to operate with QRhi instead of calling 
>> glWhatever() 
>> directly (when the application opted in for this; changing or removing 
>> anything on the gl* code path is Qt 6 material). This way all the scenegraph 
>> goodies like the batching renderer, texture atlasing, distance field based 
>> text rendering, and the ability to do custom materials will be available.
>> All this comes with the disclaimer that this, if materializes, is going to 
>> be 
>> an early preview, and some Qt Quick features will most certainly not yet be 
>> available. So not intended for production use.
>> Best regards,
>> Laszlo
>> ___
>> Development mailing list
>> Development@qt-project.org <mailto:Development@qt-project.org>
>> https://lists.qt-project.org/listinfo/development
> 
> 
> ___
> Gerrit-admin mailing list
> gerrit-ad...@qt-project.org
> https://lists.qt-project.org/listinfo/gerrit-admin
> 

-- 
---
Kari Oikarinen
Senior Software Engineer

The Qt Company
Elektroniikkatie 13
90590, Oulu, Finland
kari.oikari...@qt.io
+358 50 5281010
http://qt.io
---
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] CMake branch

[Kari Oikarinen]

Never mind. The issue is of course that changes need to go through CI, even 
though it doesn't check them.

-- 
Kari

On 21.3.2019 14.21, Mikhail Svetkin wrote:
> It will not block CI.
> 
> 
> 
> 
> Best regards,
> Mikhail
> ----
> *From:* Kari Oikarinen
> *Sent:* Thursday, March 21, 2019 1:13 PM
> *To:* Mikhail Svetkin; development@qt-project.org
> *Subject:* Re: [Development] CMake branch
> 
> 
> On 21.3.2019 14.00, Mikhail Svetkin wrote:
>> *
>> 
>> *
>> 
>> Hi everyone!
>> 
>> 
>> We’ve had an internal discussion about wip/cmake branch.
>> 
>> 
>> We thought maybe it is a good idea to merge wip/cmake into dev branch.
>> 
>> 
>> The advantages are:
>> 
>>   - It allows our contributors to play with CMake in dev branch
>> 
>>   - Speed-up the build of QtBase
>> 
>>   - Easy to find a lot of bugs in CMake port
>> 
>>   - CI could have a nightly build with CMake and generate a report
>> 
>>   - We can synchronize CMakeFiles and *.pro files
>> 
>> 
>> The disadvantages are:
>> 
>>   - Any changes should be passed by CI
>> 
>> 
>> Do you have any objections?
>> 
>> **
>> 
> 
> Would this have blocking CI or not? The stated disadvantage (which surely
> shouldn't be entirely negative) implies that it would be. But the build being
> nightly hints that it would not be.
> 
> A blocking build would mean that all changes need to leave the CMake build
> working. So everyone would need to take care of both build systems. A more
> defined transition point and only one official build system at a time would be
> nicer. Or at least trying to minimize the time of having two.
> 
> Unless of course we'd already be ready to drop building Qt with qmake, but I
> guess that's not where we are yet. Is that expected to happen during 5.x 
> series
> at all or only with Qt 6?
> 
> -- 
> Kari

-- 
---
Kari Oikarinen
Senior Software Engineer

The Qt Company
Elektroniikkatie 13
90590, Oulu, Finland
kari.oikari...@qt.io
+358 50 5281010
http://qt.io
---
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] CMake branch

[Kari Oikarinen]

Could you explain the stated disadvantage further then?

-- 
Kari

On 21.3.2019 14.21, Mikhail Svetkin wrote:
> It will not block CI.
> 
> 
> 
> 
> Best regards,
> Mikhail
> ----
> *From:* Kari Oikarinen
> *Sent:* Thursday, March 21, 2019 1:13 PM
> *To:* Mikhail Svetkin; development@qt-project.org
> *Subject:* Re: [Development] CMake branch
> 
> 
> On 21.3.2019 14.00, Mikhail Svetkin wrote:
>> *
>> 
>> *
>> 
>> Hi everyone!
>> 
>> 
>> We’ve had an internal discussion about wip/cmake branch.
>> 
>> 
>> We thought maybe it is a good idea to merge wip/cmake into dev branch.
>> 
>> 
>> The advantages are:
>> 
>>   - It allows our contributors to play with CMake in dev branch
>> 
>>   - Speed-up the build of QtBase
>> 
>>   - Easy to find a lot of bugs in CMake port
>> 
>>   - CI could have a nightly build with CMake and generate a report
>> 
>>   - We can synchronize CMakeFiles and *.pro files
>> 
>> 
>> The disadvantages are:
>> 
>>   - Any changes should be passed by CI
>> 
>> 
>> Do you have any objections?
>> 
>> **
>> 
> 
> Would this have blocking CI or not? The stated disadvantage (which surely
> shouldn't be entirely negative) implies that it would be. But the build being
> nightly hints that it would not be.
> 
> A blocking build would mean that all changes need to leave the CMake build
> working. So everyone would need to take care of both build systems. A more
> defined transition point and only one official build system at a time would be
> nicer. Or at least trying to minimize the time of having two.
> 
> Unless of course we'd already be ready to drop building Qt with qmake, but I
> guess that's not where we are yet. Is that expected to happen during 5.x 
> series
> at all or only with Qt 6?
> 
> -- 
> Kari

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

Re: [Development] CMake branch

[Kari Oikarinen]

On 21.3.2019 14.00, Mikhail Svetkin wrote:
> *
> 
> *
> 
> Hi everyone!
> 
> 
> We’ve had an internal discussion about wip/cmake branch.
> 
> 
> We thought maybe it is a good idea to merge wip/cmake into dev branch.
> 
> 
> The advantages are:
> 
>   - It allows our contributors to play with CMake in dev branch
> 
>   - Speed-up the build of QtBase
> 
>   - Easy to find a lot of bugs in CMake port
> 
>   - CI could have a nightly build with CMake and generate a report
> 
>   - We can synchronize CMakeFiles and *.pro files
> 
> 
> The disadvantages are:
> 
>   - Any changes should be passed by CI
> 
> 
> Do you have any objections?
> 
> **
> 

Would this have blocking CI or not? The stated disadvantage (which surely
shouldn't be entirely negative) implies that it would be. But the build being
nightly hints that it would not be.

A blocking build would mean that all changes need to leave the CMake build 
working. So everyone would need to take care of both build systems. A more
defined transition point and only one official build system at a time would be
nicer. Or at least trying to minimize the time of having two.

Unless of course we'd already be ready to drop building Qt with qmake, but I
guess that's not where we are yet. Is that expected to happen during 5.x series
at all or only with Qt 6?

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] codereview, merge please

[Kari Oikarinen]

On 21.2.2019 9.08, Martin Koller wrote:
> On Freitag, 15. Februar 2019 11:08:18 CET Andy Shaw wrote:
>> Since it has the +2 you can click on the "Merge patch 2 to staging" now, is 
>> that button showing up for you?
> 
> So now I did merge it to staging, but I got a "Qt CI Bot" mail stating that
> "Continuous Integration: Failed"
> https://testresults.qt.io/coin/integration/qt/qtbase/tasks/1550613219
> 
> I have no idea how a DBus test could be influenced by my commit.
> Should I just try to merge again or what is the correct procedure ?

Yes, if the failure is unrelated to your commit, just merge the patch to staging
again.

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Gerrit-admin] Branch for Qt 6

[Kari Oikarinen]

qt/qtbase now has a branch wip/qt6.

On 15.2.2019 10.03, Lars Knoll wrote:
> Let’s also conclude this thread. Majority consensus was that we need a branch 
> and most votes went towards wip/qt6. So let’s use that for Qt 6 related work 
> and 
> create the required branch.
> 
> The following rules apply:
> 
> * We CI test the branch on (at least) a reduced set of platforms/compilers. 
> Minimum is one Windows/Linux/macOS platform.
> * dev gets merged into wip/qt6 on a regular basis
> * Don’t remove any functions from wip/qt6 unless they are marked as 
> deprecated 
> in dev or else you have discussed it on the mailing list and gotten 
> maintainer 
> approval for the removal
> * Do not break source compatibility without maintainer approval
> * Breaking binary compatibility is ok
> * Breaking internal API is in principle ok, but it’s the responsibility of 
> the 
> one doing the changes to help all other modules that are using that API to 
> get 
> ported. Be careful with those changes until we get the new module testing 
> strategy implemented (see my other email on the Qt modules thread)
> 
> Gerrit admins, can you create the branch for qtbase? If others maintainers 
> want 
> a wip/qt6 branch for their repositories, please create those as well.
> 
> Let’s also hope that we now get the now sha1 pinning approach for module 
> testing 
> quickly to make handling of API changes across repo boundaries simpler.
> 
> Cheers,
> Lars
> 
>> On 16 Jan 2019, at 14:28, Shawn Rutledge > <mailto:shawn.rutle...@qt.io>> wrote:
>>
>>
>>
>>> On 16 Jan 2019, at 10:08, Lars Knoll >> <mailto:lars.kn...@qt.io>> wrote:
>>>
>>>> On 16 Jan 2019, at 09:47, Alex Blasche >>> <mailto:alexander.blas...@qt.io>> wrote:
>>>>
>>>>> From: Development >>>> <mailto:development-boun...@qt-project.org>> on behalf of Lars Knoll 
>>>>> mailto:lars.kn...@qt.io>>
>>>>> For now I’d like to limit this to qtbase, as that’s where pretty much all 
>>>>> Qt 6 related work happens,
>>>>> and we need to do some work on the CI side to prepare the other modules 
>>>>> for 
>>>>> Qt 6 related work
>>>>> (Frederik will post details in a separate mail).
>>>>
>>>> Lars, could you please elaborate on this point? What does for now mean? 
>>>> What 
>>>> time frames are we talking about?
>>>> Where does the assumption come from that all Qt 6 related work happens in 
>>>> qtbase only?
>>>>
>>>> I think I know what you might want to say but the above is too absolutely 
>>>> phrased and I want the statement clear and not fuzzy. Hence please 
>>>> elaborate.
>>>
>>> Currently, most of the efforts towards Qt 6 are preparations that are 
>>> happening in qtbase, so I believe we need the branch there now, so at least 
>>> some work start.
>>>
>>> For other modules, we will of course also need Qt 6 related branches as 
>>> soon 
>>> as possible. But we do need to get the model on how to work in those with 
>>> respect to our CI in order first. The problem here is that our CI makes 
>>> working with source incompatible changes difficult between repositories. I 
>>> believe we’ll need to fix that before we can create qt6 branches for the 
>>> other repositories that compile and test against qtbase/qt6.
>>>
>>> Of course you could create a wip branch for other repositories now as well 
>>> to 
>>> do Qt 6 related work that doesn’t require Qt6 related changes from qtbase.
>>
>> I thought the plan before was to use version checks like
>>
>> #if QT_VERSION >= QT_VERSION_CHECK(6, 0, 0)
>>
>> And so we have some of those.  But it hasn’t been clear how to test them (or 
>> at least I didn’t take the time to figure it out).  I would have liked to 
>> start doing builds like that regularly a couple years ago.  We should have 
>> had 
>> a configure option for that already, as soon as we started doing that, IMO.
>>
>> But as soon as qtbase has a qt6 branch, configure in that branch will set 
>> that 
>> version, and then we can build other modules and test that conditional Qt 6 
>> functionality, right?
>>
>> As soon as we have a qt6 branch for a given module, should we start removing 
>> the version checks and the Qt5-specific code?  Or will we put that off until 
>> nearer the Qt 6 release?
>>
>> Which way is going to make merges easier?
>>
>> ___
>> Development mailing list
>> Development@qt-project.org <mailto:Development@qt-project.org>
>> https://lists.qt-project.org/listinfo/development
> 
> 
> ___
> Gerrit-admin mailing list
> gerrit-ad...@qt-project.org
> https://lists.qt-project.org/listinfo/gerrit-admin
> 

-- 
---
Kari Oikarinen
Senior Software Engineer

The Qt Company
Elektroniikkatie 13
90590, Oulu, Finland
kari.oikari...@qt.io
+358 50 5281010
http://qt.io
---
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Kari Oikarinen]

On 28.1.2019 15.09, Jedrzej Nowacki wrote:
> On Thursday, January 24, 2019 3:18:59 PM CET Kari Oikarinen wrote:
>> On 24.1.2019 16.15, Edward Welbourne wrote:
>>
>>> Kari Oikarinen (24 January 2019 15:02)
>>>
>>>> The rest of the paragraph talks about a situation where we will have two
>>>> stable
>   branches alive at the same time. Typically we don't, because
>>>> once 5.x+1 is created, 5.x is closed.
>>>
>>>
>>> Not quite: once 5.x+1 is *released*, 5.x (if not LTS) is closed
>>> (unless we have a pressing reason to release another 5.x.y).
>>> So, in the interval between 5.x+1 branching and releasing,
>>> we have three branches.
>>
>>
>> Right, so typically we indeed have two stable branches open. Thanks for
>> correcting me.
>>
>>
>>>
>>>
>>>> But 5.12 is an LTS version, so it will still stay open.
>>>
>>>
>>> Indeed.
>>>
>>>
>>>> But at what point (under current process) would be switch it to
>>>> cherry-pick only
>   mode? I don't remember when it happened for 5.9. It
>>>> could be when 5.13 is created and then there would be no release blocked
>>>> by waiting for a merge.>
>>>
>>> We switch to cherry-picking into 5.12 when 5.14 is created.
>>> See QUIP-5,
>>> * https://quips-qt-io.herokuapp.com/quip-0005.html
>>>
>>> So creation of 5.14 switches our merge pattern from 5.12->5.13->dev
>>> to 5.13->5.14->dev and the 5.14 release (probably) closes 5.13.
>>> Again, we could of course change that.
>>
>>
>> Yes, but I was attempting to describe the current approach and messed it
>> up.
>   
>> -- 
>> Kari
> 
> 
> Well, you are still right about the fact that 5.x.z is not in cherry-pick mode
> always. How it can happen that people involved in the process aren't always
> correct about branching model.  That is simply too complex to follow.

Yeah, being hard to understand is a disadvantage of the current model.

Part of the difficulty is also just the need to be aware of the current status
of the branches with respect to release status. Your cherry-pick proposal dodges
that with the keywords used in Applies-to field. It requires the bot to
understand that. If you take that away, I would guess that contributors would
not find it easier to pick all the correct branches to cherry-pick to compared
to picking the right branch to submit to.

I could imagine a similar approach used for current model to help in choosing
the right branch to submit. So picking from dev, stable, LTS and LTS-strict
would tell you the correct branch to submit to.

Also about the releases waiting for merges. Even if we have two stable branches
active and we would then have a blocker relevant for both 5.13.0 and 5.12.2,
there is no need to wait for merges. If those release branches already exist,
then they won't be merged into. So waiting for the fix to be merged into 5.13
won't change the cherry-pick operation; the two heads and the common ancestor
stay the same. Thus once the fix lands in 5.12.2, it can then be directly
cherry-picked to 5.13.0. It would have to be cherry-picked anyway.

> Btw. it also may add one merge to all merges count I mentioned befor

True.

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Kimmo Ollila for Approver

[Kari Oikarinen]

On 25.1.2019 12.43, Ville Voutilainen wrote:
> On Fri, 25 Jan 2019 at 10:22, Teemu Holappa  wrote:
>>
>> Hello All,
>>
>> I'd like to nominate Kimmo Ollila for Approver. He has joined The Qt Company 
>> more than five years ago. Lately he has been working on INTEGRITY RTOS 
>> support and maintenance.
> 
> 
> +1.

+1, with the disclaimer that I'm in the neighboring room in the office.

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Kari Oikarinen]

First the change would need to land in the targeted branch, then the 
cherry-picks to other branches.

Batching and controlled intervals are possible, but taken to an extreme they
would replicate the current load as a group of commits would be taken in a
single build as with merges currently. If there's less batching, there are more
integrations and thus more load. Could be only a little more, of course.

A lot of the stated advantages have also been about how creators of the changes
can take ownership of them and how changes can proceed into other branches
indepently. If you are can (and are responsible for) staging the cherry-picks if
the initial stage is not successful, how would you ensure the batching?

Sometimes there are conflicts in the cherry-picks. Will other changes in the
same batch wait for them to be fixed? Or is the batching smart enough to
understand whether there is a dependency or not?

I think there is a risk of reinventing the merges here. Or if not reinvention,
at least creating a new tool that is going to see feature creep like Sergio's
mail hinted from experience.

-- 
Kari

On 25.1.2019 11.50, Simon Hausmann wrote:
> 
> The first attempt at getting a change in is distributed over multiple 
> branches. 
> The staging of the cherry-pick can happen in batches and controlled intervals 
> as 
> with merges.
> 
> 
> 
> Simon
> 
> --------
> *From:* Kari Oikarinen
> *Sent:* Friday, January 25, 2019 10:41:21 AM
> *To:* Simon Hausmann; Lars Knoll; Ville Voutilainen
> *Cc:* Qt development mailing list
> *Subject:* Re: [Development] Proposal: New branch model
> How would the CI load not change? Rather than one merge bringing multiple
> commits, each change would still be picked individually.
> 
> I also think the cherry-picking model makes more sense when branches with less
> action get the cherry-picks. The cherry-picking conflict issues grow as the
> amount of changes grow.
> 
> If we want more cherry-picking, I think we should rather pick the most frozen
> branches not yet in cherry-picking to convert. That of course would only help
> with (1).
> 
> -- 
> Kari
> 
> On 25.1.2019 11.10, Simon Hausmann wrote:
>> 
>> I think it's worthwhile to develop the tooling to automate cherry-picking. 
>> That
>> tooling is something that is perhaps best tried on a release branch first.
>> 
>> 
>> I do quite like what Allan suggested: We could try the cherry-pick the other 
>> way
>> around. Volker, Lars, Thiago etc. surely remember the p4i script we used to 
>> have
>> when we were using Perforce. Imagine that with more automation.
>> 
>> 
>> (1) Liang's work load gets reduced dramatically - conflict resolution is 
>> distributed.
>> 
>> (2) Changes hit the customer relevant branch ASAP.
>> 
>> (3) The load on the CI does not change for anybody working in dev.
>> 
>> 
>> 
>> 
>> Simon
>> 
>> 
>> *From:* Lars Knoll
>> *Sent:* Friday, January 25, 2019 9:05:45 AM
>> *To:* Ville Voutilainen
>> *Cc:* Simon Hausmann; Qt development mailing list
>> *Subject:* Re: [Development] Proposal: New branch model
>>> On 24 Jan 2019, at 22:29, Ville Voutilainen  
>>> wrote:
>>> 
>>> On Thu, 24 Jan 2019 at 20:26, Simon Hausmann  wrote:
>>>> 
>>>> 
>>>> I would see the biggest long term impact with the massive amount of cherry 
>>>> picks from dev to qt6 over a long period of time.
>>>> 
>>>> Git rerere works locally, so it doesn’t help in this setup I think.
>>> 
>>> Completely seriously, without any preference to either branching
>>> approach: aren't we going to be in some sort of trouble
>>> with the qt6 branch anyway, no matter what we do? Following on a bit:
>>> 
>>> Pardon me if I missed some important part of the motivation of all of
>>> this, but I *CAN'T* see how this should, could,
>>> or needs to be an approach that helps with the qt6 branch
>>> merge/cherry-pick/rebase. I don't think that's going to
>>> be a pleasant operation whatever we do.
>>> 
>>> I would like a "push to trunk, backport to release-branches" approach
>>> going forward. As in, once we have the usual
>>> umpteen X.y branches, it's a simple approach.
>>> 
>>> But I don't see how going from merge-forward (except also
>>> merge-backward sometimes) to cherry-pick-backward
>>> (except also cherry-pick forward, or kinda sideways to qt6, and maybe
&

Re: [Development] Proposal: New branch model

[Kari Oikarinen]

> two 
> changes, one for Qt6 and one for Qt5. That’s not very different from the 
> situation we had with Qt 4 some years ago.
> 
> Cheers,
> Lars
> 
>> 
>> Qt6 and dev are going to diverge. Drastically, eventually. I don't
>> know how to solve that. A new branching policy
>> is not going to help with that.
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
> 

-- 
---
Kari Oikarinen
Senior Software Engineer

The Qt Company
Elektroniikkatie 13
90590, Oulu, Finland
kari.oikari...@qt.io
+358 50 5281010
http://qt.io
---
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Nominating Sami Nurmenniemi for Approver status

[Kari Oikarinen]

Hi!

I'd like to nominate Sami Nurmenniemi for Approver. He has already been working
in The Qt Company in the same team as I am for a good while.

Sami has worked on (among other things):

- Improving flaky tests
- CI coverage for ARM platforms by using user mode QEMU
- Demos for embedded devices

He is a careful and competent developer and reviewer. I trust he would wield his
new powers with good judgment.

His changes:

https://codereview.qt-project.org/#/q/owner:%22Sami+Nurmenniemi+%253Csami.nurmenniemi%2540qt.io%253E%22,n,z

His reviews:

https://codereview.qt-project.org/#/q/reviewer:%22Sami+Nurmenniemi+%253Csami.nurmenniemi%2540qt.io%253E%22,n,z

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Kari Oikarinen]

On 24.1.2019 16.15, Edward Welbourne wrote:
> Kari Oikarinen (24 January 2019 15:02)
>> The rest of the paragraph talks about a situation where we will have two 
>> stable
>> branches alive at the same time. Typically we don't, because once 5.x+1 is
>> created, 5.x is closed.
> 
> Not quite: once 5.x+1 is *released*, 5.x (if not LTS) is closed
> (unless we have a pressing reason to release another 5.x.y).
> So, in the interval between 5.x+1 branching and releasing,
> we have three branches.

Right, so typically we indeed have two stable branches open. Thanks for 
correcting me.

> 
>> But 5.12 is an LTS version, so it will still stay open.
> 
> Indeed.
> 
>> But at what point (under current process) would be switch it to cherry-pick 
>> only
>> mode? I don't remember when it happened for 5.9. It could be when 5.13 is
>> created and then there would be no release blocked by waiting for a merge.
> 
> We switch to cherry-picking into 5.12 when 5.14 is created.
> See QUIP-5,
> * https://quips-qt-io.herokuapp.com/quip-0005.html
> 
> So creation of 5.14 switches our merge pattern from 5.12->5.13->dev
> to 5.13->5.14->dev and the 5.14 release (probably) closes 5.13.
> Again, we could of course change that.

Yes, but I was attempting to describe the current approach and messed it up.

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Kari Oikarinen]

On 24.1.2019 15.15, Jedrzej Nowacki wrote:
> Last, but not least. The release branches are already in cherry-pick mode, so
> again it is not different, amount of conflicts is the same, true one needs to
> solve them earlier,  but on the other hand you can prepare the conflict
> resolution in parallel, while waiting for the integration. In your example you
> picked an easy target, but try the same with 5.13 and case of a fix targeting
> LTS. With the current model you need one merge (5.12 -> 5.13) and then one
> cherry-pick (5.13 -> 5.13.x). Of course you could cherry-pick from LTS
> directly to the release branch, but then you are acknowledge that merges are
> hurting us in terms of release speed.

Our release branches aren't in cherry-pick mode. If you have a blocker fix for
5.12.1 right now, it should be submitted into 5.12.1. The changes will reach
5.12 by a merge that will be done later. Based on a quick look qtbase 5.12.1 had
only one cherry-pick since the downmerge, so cherry-picking into release
branches is an exception, not the rule.

The rest of the paragraph talks about a situation where we will have two stable
branches alive at the same time. Typically we don't, because once 5.x+1 is
created, 5.x is closed. But 5.12 is an LTS version, so it will still stay open.
But at what point (under current process) would be switch it to cherry-pick only
mode? I don't remember when it happened for 5.9. It could be when 5.13 is
created and then there would be no release blocked by waiting for a merge.

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Kari Oikarinen]

On 24.1.2019 15.10, Edward Welbourne wrote:
> Dnia czwartek, 24 stycznia 2019 09:08:29 CET Liang Qi pisze:
>>> My concern is about "cherry-pick" a series of changes for a big
>>> feature, especially during the period to have "dev" branches for both
>>> 5 and 6. I don't have solution for this issue yet.
> 
> Jedrzej Nowacki (24 January 2019 11:53)
>> My assumption is that bot would cherry-pick them in the same order in
>> which patches got integrated to dev. That way we could reduce amount
>> of issues. Of course if the first patch from a series causes conflicts
>> then all other would also be in conflict.
> 
> Well, the *initial* cherry-pick-and-send-to-Coin can be made to happen
> in the same order; but after that, any that didn't get through on the
> first pass are going to be apparently-unrelated changes waiting to go
> into the destination branch.  The script might be able to look at the
> upstream dev versions of its cherry-picks and reproduce the dependencies
> among them, but that's going to get tricky when some of those upstream
> changes got integrated out of order (because some of them were merely
> later in the branch, without a strict dependence on those earlier) or
> some of them succeed on the first pass while others, before and after
> them on the original branch, fail.  Either you'll end up losing some
> dependency relations or you risk having things on my branch depend on
> other folks' unrelated changes that were just upstream of my branch,
> that haven't yet made it through cherry-picking.  This isn't fatal, as
> the developer taking care of the post-failure fix-up and/or retries can
> stage despite a dependency missing, but it'll cause some pain at times.
> 
> There are also potential problems where I push to dev a fix for some
> issue, followed by a change that undoes a kludge-around whose root cause
> is the issue I've just fixed, but which was put there to fix some
> seemingly unrelated issue.  Even if the first fix's cherry-pick hits a
> conflict or fails to integrate, it's entirely possible that the removal
> of the kludge-around gets through on the first pass; and that could be a
> problem.  With luck there's a test for what it kludged round, that'll
> prevent it integrating; but, if there isn't, that issue resurfaces in
> the target branch until the real fix's cherry-pick lands.
> 
> Automated cherry-picking implies various complications that we haven't
> fully explored; whereas merges have some well-established reliable
> properties that avoid many of those complications.  Engineers prefer
> what's known, from experience, to work over things that sound like they
> might.  OTOH, as Ville points out, other projects do use cherry-picking;
> so perhaps we need more information from such projects,

We're also using cherry-picking ourselves in LTS branches. At least older ones,
5.12 is not at that mode yet. As far as I know it has been working well.

Since the problems with cherry-picking come up as the changes pile up and
concurrent development happens, those are largely avoided in the older branches.

A less ambitious change to our current process could be moving branches into
cherry-picking mode earlier. That would limit the count of currently active
branches that we need to merge between. Of course the effects of such a change
would be much smaller also. But just to mention it because I don't think anyone
has mentioned it yet.

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Kari Oikarinen]

On 23.1.2019 17.51, Jedrzej Nowacki wrote:
>Can we use annotate instead of cherry-pick -x?
>--
> 
>No, but we should use it in addition. Annotations are mutable, therefore 
> are
> not 100% trust worthy. If we have both, we could validate annotations against
> commit message, sadly it would not protect against annotation removal.

What are these annotations? I tried to google them but only found documentation
for git-annotate, which is just git-blame with a different output format.

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Kari Oikarinen]

On 24.1.2019 11.49, Edward Welbourne wrote:
> Olivier Goffart (24 January 2019 08:03)
>> Let's start by looking at the "problem"
> 
> Always a good place to start.
> 
> On 23.01.19 16:51, Jedrzej Nowacki wrote:
>>> My impression is that the current model works great for a single
>>> release branch, but we have: 5.6 5.9 5.12 and soon we will have 5.13,
>>> that is without counting temporary patch level branches.
> 
>> But the LTS and patch level branches are already in cherry-pick mode!
> 
> Indeed: Jedrzej does here over-state the problem.
> 
>> So we have only ever have one release branch. Therefore the current
>> model works great (your own words).
> 
> We routinely have two branches other than dev that are merged up to dev,
> one via the other.  Thus, until 5.11 closed, we were merging 5.11 up
> through 5.12 to dev; once 5.13 branches, we'll be merging 5.12 through
> 5.13 up to dev.  Once 5.13 closes, we'll put 5.12 in cherry-pick mode
> and be back to just one (as we are right now, temporarily); but wne 5.15
> branches we'll be back to 5.14 -> 5.15 -> dev again.  Then, of course,
> we also have the 5.x.y branches transiently, which does complicate life,
> but I'm going to leave it out of my analysis.
> 
> So some of the time we have three branches, some of the time two,
> between which we merge; plus we have an LTS or two to which we
> cherry-pick.  (Which means we mix models.)
> 
> However, merge-mode always implies more delay for a change's propagation
> compared to the cherry-pick model, at least when the developer whose
> change is considered is eager to get it propagated.

In general it leads to a longer delay until the change is in all relevant
branches. It does however lead to a change getting into the branch closest to
release faster, because it doesn't need to get into dev first. Branches close to
release are an important case.

Yes, you can deviate from the process in urgent cases. But even if the release
is not right at the door to justify the deviation, the change landing sooner
gives more time to find any possible issues in it.

> 
>>> Merging through them is hard, we already had to use "cherry-pick
>>> mode" in some places. When we add to the picture dev and qt6
>>> branches, merging will be very, very hard. It is practically a full
>>> time job to update qt5 repository and coordinate all the merges now
>>> (thank you Liang!),
> 
>> But as other have already said, the total amount of work would still be the
>> same. Actually worse since one would have to manually stage the patch and 
>> fail
>> the tests and resolve the conflicts that happen between them as they may 
>> occurs
>> in different order.  Overall, i'd say this is much more burden for branches
>> which still are supposed to get lots of patches.
> 
> There would, indeed, be extra staging with the proposed model; and
> patches may land in a different order.  The latter bothers me more.

Add to that the fact that a long-lived branch that is cherry-picked to may lead
to having to resolve the same conflict multiple times. (As discussed elsewhere
in the thread.)

Especially so for qt6 branch, which would be getting almost every change made in
dev + API breaking changes preparing for Qt 6. How many changes will actually
have the no-future tag?

>>> shortly after qt6 branch opening amount of work will be much bigger.
> 
>> But I fail to see how the proposed model helps with that in any way.
> 
> ... and we'll eventually have to merge the qt6 branch with dev, which is
> going to be "fun" if they've had cherry-picks between them that have had
> conflicts (as we can expect) that have been resolved.  Whoever does that
> merge is going to wish we'd been using merges from dev to qt6 earlier.

If I understood the proposal right, there wouldn't be a merge from dev into the
qt6 branch. Rather the dev branch would be deleted and the qt6 branch renamed to
dev. It already has all the changes, except those with the tag no-future

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Kari Oikarinen]

On 24.1.2019 11.11, Volker Hilsheimer wrote:
> 
> 
>> On 23 Jan 2019, at 22:09, Allan Sandfeld Jensen > > wrote:
>>
>> On Mittwoch, 23. Januar 2019 21:42:35 CET Edward Welbourne wrote:
>>> Jedrzej Nowacki wrote:
> Advantages:
> - no waiting for merges, a fix can be used right away after
>
>   integration
>
> - faster propagation of fixes targeting all branches, as there are
>
>   no merges of merges
>>>
>>> Alex Blasche (23 January 2019 18:09)
>>>
 This is pure speculation because you potentially triple (or worse) the
 amount of individual patches requiring a merge in gerrit when you
 consider that you want to at least merge to 5.9, 512, dev and qt6. I
 don't see this prediction come true.
>>>
>>> Well, as soon as it hits dev, the patch is cherry-picked to every branch
>>> that its footer says it belongs in.  Those branches where all goes well
>>> see it one integration later.  Each branch that has a conflict needs
>>> that resolved before we get to that second integrtion.  Contrast this
>>> with a 5.12 -> 5.13 -> dev chain of merges, where dev doesn't get the
>>> change that landed in 5.12 (even if that change could land in dev
>>> without conflict) until
>>> * there's been some delay between their change being accepted in 5.12
>>>   and the next merge-bot run
>>> * everyone who made change to 5.12 that conflicted on merging to 5.13
>>>   has advised Liang on how to resolve their conflicts
>>> * we've got the result through integration into 5.13
>>> * everyone who's made changes to 5.13 or (as possibly just amended in
>>>   merging) 5.12 that conflicts with anything in dev has again advised
>>>   how to resolve their conflicts
>>> * and we've got the result through a second integration, into dev.
>>>
>>> When nothing but the change being considered has a conflict along
>>> the way, that's twice as long; and any change to an upstream branch,
>>> that does have a conflict, introduces delay for all the other changes
>>> that landed in that branch, even if they don't have conflicts.  In the
>>> middle of summer, when lots of folk are away on holiday, getting help
>>> with resolving conflicts isn't easy - the folk who know those commits
>>> won't be back for a month - and all changes, no matter how urgent, get
>>> stuck behind any conflict we can't work out how to resolve.
>>>
>>> So no, Jedrzej's claim is not *pure* speculation; it's at least quite a
>>> lot adulterated with reasons to believe that many changes would, under
>>> his scheme, propagate to all branches they're destined for sooner than
>>> happens with our present scheme.
>>>
>> No, it is speculation, and it optimizing the least important case: bug-fixes
>> in dev. Dev is the branch that can wait the longest to get a bug-fix, the
>> stable branch is the branch that need it the most urgent. And fixing a bug in
>> 5.12 now means you first fix it where you need it (5.12), then rewrite it for
>> dev, then resolve the inevitable conflict back so it can be merged, all
>> waiting for bots and release teams to stumple into the issues and delaying 
>> the
>> next 5.12.x release.
>>
>> ‘Allan
> 
> 
> More people working and building against dev helps keep dev more stable (by 
> virtue of discovering breakage sooner), and the proposal encourages more 
> people 
> to work on dev. That can be a good thing.

Our users use our releases. Our development process should aim at producing good
releases (at scheduled times). This proposal is putting more focus on dev, but
will it lead to better quality releases? Users won't care about a dev branch
that gets fixes sooner, if they have to wait for those important fixes longer
than in the current situation.

> 
> Urgency to get fixes into a stable branch is an argument that has come up a 
> few 
> times. The current 5.12.1 release seems to be delayed because some changes 
> made 
> it into 5.12 that shouldn’t have been there in the first place (given the 
> definition of “stable”). It would be interesting to see some data about how 
> many 
> point releases we had to delay because “highly desirable fix for old bug was 
> stuck in the process” vs “regression was introduced in a stable branch and 
> only 
> discovered during release testing”.

The absolute path changes got into 5.12.1 due to an explicit wish to have them
in a fresh LTS branch early. Reviewers accepted that and could have done so
under both models as easily.

The argument that these changes help by reducing changes in stable branches is
that currently people are putting in changes that don't belong there. Making
getting changes into stable branches more painful with the new model will lead
to less changes getting in. This will happen due to people avoiding work they
can avoid.

Importantly this is not the same thing as more careful consideration about
whether a change *should* go to the stable branch. The changes will be selected
based on how persistent people are, not on how 

Re: [Development] Proposal: New branch model

[Kari Oikarinen]

On 24.1.2019 11.13, Edward Welbourne wrote:
> 23.01.2019, 21:38, "Alex Blasche" :
 At the end of the day each cherry-pick is a merge too
> 
> Merges and cherry-picks have a certain amount in common, but they are
> not the same thing at all.
> 
 and they can conflict too. The conflict resolution process is still
 the same. if everything is conflict free then a git merge would be
 no more difficult than a cherry-pick.
> 
> This is true.
> 
> On Mittwoch, 23. Januar 2019 19:43:06 CET Konstantin Tokarev wrote:
>>> And when conflicts are present, cherry-picking N patches may result in N
>>> times more work than merge in worst case (and same amount of work in the
>>> best case)
> 
> Allan Sandfeld Jensen (23 January 2019 23:05)
>> More than that. Once you have had cherry-pick only for a while git will be
>> unable to find useful common ancestors for the changes, and will be unable to
>> do smart three-way merging of cherry-picks,
> 
> OK, now you're just engaging in ill-informed FUD.
> Cherry-picks do not involve any three-way anything.
> You clearly do not understand the difference between merging and
> cherry-picking.
> 
> A cherry-pick takes the diff involved in one commit and patches another
> check-out with it.  A merge uses the digraph of commits in sophisticated
> ways; a cherry-pick does not.
> 

Quoting man page for git-cherry-pick: https://git-scm.com/docs/git-cherry-pick

"For conflicting paths, the index file records up to three versions, as 
described in the "TRUE MERGE" section of git-merge[1]. The working tree files 
will include a description of the conflict bracketed by the usual conflict 
markers <<< and >>>."

It is similar enough that it actually refers to the same section of
documentation!

But it doesn't actually create a new common ancestor for the commits. So every
further cherry-pick can still hit the same conflict. Instead of being resolved
by the merge, there's an unbounded amount of time that different people will hit
it and need to resolve it.

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Requests for Gerrit admins

[Kari Oikarinen]

Gerrit was for a long time taken well care of by Ossi and Frederik. In
connection with Ossi's departure we've added a couple of new admins:

- Kari Oikarinen
- Paul Wicking
- Jukka Jokiniva

Frederik Gladhorn continues as well. Given the larger amount of people, to avoid
duplicate work we'd like to move the requests over to using Jira. This also
ensures a higher-level of transparency and lets us track the status of related
tasks. In the event that a request may have privacy implications, you can still
contact us directly by emailing gerrit-ad...@qt-project.org.

So in the future when you have a request you would have previously sent directly
to Ossi or the gerrit-ad...@qt-project.org mailing list, instead create a task
in the QTQAINFRA project with the component Gerrit.

By sending requests to the whole group (by allowing the Jira ticket to be
auto-assigned), you'll be served by the first available admin. This leads to
faster service than asking a specific admin directly.

Actions that are decided based on Qt Project Open Governance must still go
through the development mailing list, so participants of the governance process
don't need watch the Jira queue. You can of course add the ticket and refer to
it when sending the mail.

The gerrit-admin mailing list was disabled due to a misconfiguration from around
Christmas to January 11th. If you sent a request during that time that has not
been fulfilled, please ping us again.

--
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Branch for Qt 6

[Kari Oikarinen]

On 15.1.2019 14.32, Lars Knoll wrote:
>> On 15 Jan 2019, at 13:18, Tor Arne Vestbø > > wrote:
>>> On 15 Jan 2019, at 13:14, Allan Jensen >> > wrote:
>>>
>>> On Tuesday, 15 January 2019 12:22:11 CET Tor Arne Vestbø wrote:
> On 15 Jan 2019, at 12:13, Allan Jensen  > wrote:
>
> On Tuesday, 15 January 2019 12:06:17 CET Tor Arne Vestbø wrote:
>
>>> On 15 Jan 2019, at 11:54, Lars Knoll >> > wrote:
>>>
>>> Ok, guess I misunderstood a bit. My idea was to keep ‘dev’ for 5.x
>>> development and ‘qt6’ for Qt 6 related development. At some point (when
>>> 5.15 is branched) we’d basically rename qt6 to dev (because at that
>>> point
>>> there’s no 5.x anymore).
>>
>>
>> Okey, so we _will_ have parallel Qt 5 and Qt 6 feature development, and
>> in
>> that case need two “dev” branches.
>
>
>
>> I argue that instead of naming them ‘dev’ and ‘qt6’ like proposed, we
>> use
>> explicit names, either:
>
>
>
>> - 6.0 and 5.15 (if there’s no 6.1 branched 6.0 is “dev. If there’s no
>> 5.16
>> branched, 5.15 is “dev”)
>
>
> I prefer the idea of keeping dev and make it head of 5.x that very clearly
>
>>> indicates we want new feature development in 5.x not in qt6.


 At some point we _do_ want new feature development in Qt 6 (I presume). The
 names we choose now will stick, let’s be a bit proactive.
>>>
>>> At that point qt6 will become dev, and later 6.0 and dev?
>>
>> No, because Qt 5 will still have overlapping “dev” work according to Lars, 
>> so 
>> we can’t rename it to ‘dev’.
> 
> We can (and should) rename it to dev once the last 5.x version (presumably 
> 5.15) 
> reaches feature freeze (ie. in a year from now).

An alternative way of seeing (and perhaps handling) is in the same way as we
handle feature branches. The qt6/6/next/whatever branch would be for development
that can't be put into dev yet as it is not suitable for the 5.x releases.
Everything that is suitable for 5.x would still go to dev. Once the last minor
version of the 5 series of releases freezes, dev is open for 6.x stuff. Then the
qt6/6/next branch would be merged into dev and deleted.

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Requesting a repository for Lottie-Qt implementation

[Kari Oikarinen]

On 10.1.2019 15.22, Uwe Rathmann wrote:
> On Thu, 10 Jan 2019 13:24:14 +0100, Vlad Stelmahovsky wrote:
> 
>> Qwt is nice but supports only QWidgets, right?
> 
> True, but Qt/Charts is also QWidgets only.
> 

Not quite: https://doc.qt.io/qt-5/qtcharts-qmlchart-example.html

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Issues with 'Fixes' keyword

[Kari Oikarinen]

On 26.12.2018 17.58, Christian Ehrlicher wrote:
> Hi,
> 
> looks like under some circumstances the 'Fixes' keyword in the commit message 
> does trigger the automatic closing of a bug when the bug is in 'In progress' 
> state. Is this the intended behavior?

Yes. You can use the "Task-number" keyword if you want to link commits to a bug,
but still keep it open. For example if fixing it properly requires multiple
changes.

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Closing issues automatically with new keyword

[Kari Oikarinen]

On 21.09.2018 15:32, Tor Arne Vestbø wrote:



On 21 Sep 2018, at 13:32, Jedrzej Nowacki  wrote:


Shouldn’t that pick refs/heads/5.11?

Tor Arne


Yes, that is what happened. The first release branch for 5.11 is 5.11.0,
therefore it marked 5.11.0 as fixed version.


That doesn’t make any sense. The 5.11 branch is constantly moving. If it 
resolved to refs/heads/5.11, it should pick the _upcoming_ release for 5.11, or 
if there is none (in JIRA), not set a fixed version.



Normally it would find a 5.11.2 tag and thus set the fix version as 5.11.3.

The repository in particular does not have those tags, which is the root 
cause
for the script not picking the right version. We'll see if we start 
tagging it
(the version actually included in releases is determined in meta-boot2qt 
which
is tagged, so it's not mandatory) or just mark the versions for these 
bugs by

hand, which is not any more work than before the script.


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

Re: [Development] clang-format

[Kari Oikarinen]

On 20.06.2018 09:30, Lars Knoll wrote:
>
>
>> On 19 Jun 2018, at 18:19, Ville Voutilainen 
 wrote:

>>
>> On 19 June 2018 at 19:13, Philippe  wrote:
 For the above reasons I'd lean towards not running it globally and 
just using it

 on new changes.
>>>
>>> +1, based on my clang-format experience on a big application.
>>>
>>> BTW, keep in mind that you can disable clang-format on code 
sections with:

>>>
>>> // clang-format off
>>> // clang-format on
>>
>> When I last experienced a large-scale clang-format reformat, it really
>> hurt development
>> during the churn. We should somehow manage to do it during a time when
>> there aren't
>> many pending patches in the pipeline. I'm not concerned about
>> git-blame; that has never
>> been a problem after reformats. However, I do not care about
>> indentation nor do I want
>> to spend time on it either way, it has no actual effect on readability
>> and maintainability
>> of code, and consistency outside the file you're in has never mattered
>> to me one bit.
>>
>> IOW, I'm not opposed to reformats and auto-checking of clang-format
>> (or even hooking it),
>> but I do not see it as a thing with all that great return-of-investment.
>
> It helps in that you do not need to point those things out in code 
reviews, and that I (and others) won’t even create changes with wrong 
formatting that I’ll need to fix up later on. It’s part of a larger 
story, where I would like to get as much automatic checking of changes 
done before humans start reviewing.

>
> One idea could be to introduce this incrementally. Let’s first start 
off with enforcing it for new changes. Then we run it globally over the 
code base shortly before Qt 6.0 is being released. At that time merges 
shouldn’t be as much of a problem (as we’ll probably cherry-pick into Qt 
5.15) and by then all new changes in Gerrit will be properly formatted 
(due to the earlier hook).

>

I think this is a good approach. It includes a period of time between 
taking the
formatting options into use and applying them globally. There's a good 
chance
that the used clang-format settings may change due to discussion as more 
people

and code are exposed to it. It would be a shame to have to globally reformat
*again* after a short period of time.

(I'm still not sold on the benefit of running the reformatting on 
existing code
outweighs the cost, but the suggested time would probably give the best 
balance

there.)

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

Re: [Development] clang-format

[Kari Oikarinen]

On 18.06.2018 12:04, Frederik Gladhorn wrote:


Other parts sound good, so I'll just touch on the big question.

> And then there is the big question when we run it once over the entire
> codebase.

I'd hesitate to ever run it over the entire codebase.

* It will ruin plain git blame, since so much will point to that particular
  commit. Yes, you can use `git blame -w` to avoid whitespace changes, 
but that

  does not catch rewrapped lines.

* Open changes would need to be rebased on top of it. When would be a 
good point

  in time with few open changes?

* Which branch do you run it in? If an early one, there's many merges to 
do. If

  a late one, all the subsequent merges are tricky.

It is quite a bit of pain while the benefit isn't that big. Actively 
worked on
areas would shape up incrementally anyway and the other areas are not 
read that

much, so the damage of inconsistent formatting is limited.

For the above reasons I'd lean towards not running it globally and just 
using it

on new changes.

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

Re: [Development] Consistently flaky test QTabWidget test

[Kari Oikarinen]

Hi!

I'm also taking a look at it. It's my change that broke it. The issue
is that the test is getting some extra paint events on macOS.

Previously it had a qWait(1000) that waited over them.

Here's a change to add it back and stop blocking other integrations:

https://codereview.qt-project.org/#/c/227976/

--
Kari

On 02.05.2018 11:11, Richard Gustavsen wrote:

I'll take a look!


-Richard


*Fra:* Development 
 på vegne av 
Thiago Macieira 

*Sendt:* 2. mai 2018 09:46:40
*Til:* development@qt-project.org
*Emne:* Re: [Development] Consistently flaky test QTabWidget test
On Wednesday, 2 May 2018 00:29:18 PDT Thiago Macieira wrote:

8 out of 8 integrations attempted in both qtbase/dev and qtbase/5.11
yesterday resulted in


Make that 9 of 9.

I'll stop trying to stage anything in qtbase until further notice.

--
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


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

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

[Kari Oikarinen]

On 17.04.2018 12:08, Edward Welbourne wrote:

Alex Blasche (maanantai 16. huhtikuuta 2018 16.47)

... I do like to emphasize though that the dates for first beta and
first RC are important (and FF is alpha) because they define times
when certain level of changes are no longer permitted (e.g. after
first beta no API changes). Therefore, you will not get around setting
a target date for first Beta and RC.


Jani Heikkinen (17 April 2018 08:28)



So  I think the way to proceed with this should be like Lars proposed:
- Snapshot packages from the dev branch
- FF and branching occur together and packages are getting the ‘alpha’ tag
- Agree that we should start with the API review immediately.
- Beta once API review is done. Lets agree the 'Done' properly to get
   it clear for everyone. I already tried to start discussion about it in
   http://lists.qt-project.org/pipermail/development/2018-March/032338.html



- RC once we have the release branch and all currently known blockers are fixed


You'll have the release branch just after alpha, if you follow the plan
above, so the only condition left here is the known blockers.  Even on
those, we've had some flexibility in the past - some blockers do get
downgraded sometimes - which can serve to steer a release towards
fitting a schedule.


For example with 5.11.0 release there's two branching points for
branches 5.11 and 5.11.0. Maybe with release branch the latter is meant?

So dev -> 5.12 branching would happen at feature freeze and 5.12 ->
5.12.0 branching would happen in the transition to RC?

A good naming convention for those branches might help keep them
separate. "Minor branches" and "release branches" maybe?

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

Re: [Development] How to run QtBase autotests on a remote machine?

[Kari Oikarinen]

On 11.04.2018 15:06, Edward Welbourne wrote:
> Alexander Richardson (11 April 2018 10:13)
>> I am currently trying to get Qt to work on the CHERI CPU
>> (http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-faq.html)
>
> Sounds interesting.
>
>> I have now managed to get the first few unit tests to build and run as
>> CHERI pure capability programs
>
> Impressive :^>
>
>> so I would like to run the full test suite.
>
> Makes sense.
>
>> Currently I build the tests and then scp individual tst_foo binaries
>> to the host and run them manually. In order to fix the initial porting
>> problems that will show up in most tests this is fine.
>
> Some tests shall need more than the binary; e.g. data files to act on.

Unfortunately I don't know of a better way. I asked people who have been 
working

on the INTEGRITY port and they've also just made static builds of test
executables and then copied them over to the device to be run.

>
>> Is there any existing mechanism to run the unit tests on a machine
>> other than the compilation host?
>
> I hope so - does anyone know how we test on Android, iOS or any other
> cross-compilation target ?  Or do we even support testing on them ?
>

When it comes to CI, tests don't seem to be run on Android and iOS targets.
There are two cross-compilation targets (Linux arm64 and armv7) that are 
tested,

but those are under QEMU emulation, not on real hardware.

For QEMU tests the tests are run in the folder they were built in under
emulation, so they don't offer any hints on a good process for testing 
in a real

device.

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

Re: [Development] Repository request: Qt Notifier

[Kari Oikarinen]

On 15.01.2018 17:25, Ryan Chu wrote:

Hi all,

I'm working on a task supporting "Push Notification" for Qt 
applications. This feature will be implemented on Android and iOS 
devices as the first stage. A new module called "Qt Notify" will be 
created for all platforms. Therefore I request a repository.




This sounds like it overlaps with qtcloudmessaging which also seems
to be about push notifications? Or are they actually about something
different and I'm mixing things?

http://blog.qt.io/blog/2018/01/02/qt-cloud-messaging-api-available-embedded-systems/

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

Re: [Development] QML and Qt Quick versioning of our modules

[Kari Oikarinen]

On 07.12.2017 15:53, Frederik Gladhorn wrote:

1) sync minor versions to Qt release version:
For Qt 5.11, we would provide QtQuick.Controls 2.11
This way, the challenge for the user is only to find out if it's version 1, 2
or 5.



This sounds troublesome if Qt 6.0 comes when Qt Quick Controls would 
still like to stay in the same major version. 2.0?



2) Make the minor version import optional and we pick the lastest. This should
be optional to prevent the name clashes described above and shifts the risk to
the user.
In practice I'd expect this to be pretty safe.
import QtQuick.Controls 2 would then give the latest version available.

3) Make even the major version optional and we'd pick up the latest version.
import QtQuick.Controls would give version 2.11 with Qt 5.11.


Optional versions in the import statement sound good to me.

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

Re: [Development] New Qt 5.9.1 snapshot available

[Kari Oikarinen]

I believe this is https://bugreports.qt.io/browse/QTCREATORBUG-17909

--
Kari

On 28.06.2017 04:07, Vincent Hui wrote:

Hi Akseli,

Why Qt 5.9.1 for MSVC2015 version on Windows is label as "Qt 5.9.1 
MSVC2015 64bit2"? That makes me think Qt 5.9.1 is built by MSVC2015 with 
update 2 not update 3. Qt 5.9.0 for MSVC2015 version on Windows is label 
as "Qt 5.9.0 MSVC2015 64bit3". By the number 3 after "64bit", I think Qt 
5.9.0 is built by MSVC2015 with update 3.


Is Qt 5.9.1 not built by MSVC2015 with update 3?

Br,
Vincent


On Mon, Jun 26, 2017 at 11:28 PM, Akseli Salovaara 
<akseli.salova...@qt.io <mailto:akseli.salova...@qt.io>> wrote:


Hi all,

We have a new Qt 5.9.1 snapshot available via online installer. It
is a separate Qt 5.9.1 node, not as an update to Qt 5.9.0, but will
overwrite previous Qt 5.9.1 snapshot. Instructions how to install it
here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer
<https://wiki.qt.io/How_to_get_snapshot_via_online_installer>

Content of the snapshot is based on
https://codereview.qt-project.org/197790
<https://codereview.qt-project.org/197790>, delta to Qt 5.9.0 as an
attachment.

RTA testing is ongoing and excluding fix for
https://bugreports.qt.io/browse/QTBUG-61635
<https://bugreports.qt.io/browse/QTBUG-61635> Android deployment
issue this should be the final Qt 5.9.1 content. So please test the
snapshot & report your effort via
https://wiki.qt.io/Qt59_release_testing
<https://wiki.qt.io/Qt59_release_testing>

Br,
Akseli


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




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



--
---
Kari Oikarinen
Software Engineer

The Qt Company
Elektroniikkatie 13
90590, Oulu, Finland
kari.oikari...@qt.io
+358 50 5281010
http://qt.io
---
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit?

[Kari Oikarinen]

On 08.05.2017 09:47, Thiago Macieira wrote:

On Sunday, 7 May 2017 22:56:53 PDT Sergio Martins wrote:

On 2017-05-06 16:00, Thiago Macieira wrote:

Someone could do that. I'd even appreciate just a backtrace from the
deadlocked application.


Have you asked the CI guys for such backtrace ? Why isn't there a JIRA
issue for this ?


I asked for anyone who could reproduce the issue to help and no one did. And
until this discussion now, I had not realised it was connected to cross-
compilation -- though in fact we have not proven it, it's just a very good
theory.

As for a JIRA task to get backtraces from crashed or stuck applications, it
again hadn't seemed necessary so far. The qmake crash that we saw this week
was only the second time that it would have been helpful.

Well... that and all those moc crashes we experienced for a year.



The failures of https://codereview.qt-project.org/#/c/180231/ and 
https://codereview.qt-project.org/#/c/180232/ happened on Ubuntu Touch 
builds.


That platform is not part of 5.9 CI anymore. So as far as I understand 
it hasn't been tried if the patches could successfully integrate into 5.9?


Disabling cross-compilation of QtDBus would break a lot of users. 
(Including Qt for Device Creation builds.) So hopefully we can find some 
other way.


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