[Development] Request a new branch for Qt Creator

André Pönitz apoenitz at t-online.de
Tue Aug 6 19:48:36 CEST 2019


On Mon, Aug 05, 2019 at 11:48:54PM +0000, Stottlemyer, Brett (B.S.)
wrote:
> Before I address André's specific questions, let me add a little more
> context.
> 
> We have a few plugins for QtC that were developed with KDAB starting
> about 5 years ago with the development of Qt Remote Objects.  We've
> actually had several developers from The Qt Company reviewing the code
> outside of Gerrit, which has been difficult.  Moving to Qt's Gerrit
> was proposed by them (Simon Hausmann specifically).  We believe the
> code fills a hole in Qt, one that would require significant
> development effort to replicate independently.

Such context is always good.

> On 8/5/19, 1:39 PM, "André Pönitz" <apoenitz at t-online.de> wrote:
> Would it be possible to use a less overloaded name? After a bit of
> search I think I get now what it refers to, but it surely was not my
> first guess.
> 
> I'm open to changing the name of the plugin.  I'd rather discuss that
> as part of the review process though.  If we need a better name for
> the branch, is "acme-simulator" acceptable?

For me, 'ACME' probably will always trigger 'ACME Corporation' as in
https://en.wikipedia.org/wiki/Acme_Corporation, but ..

.. by now I think we can simply side step this issue of finding a name
for a branch, as I think we shouldn't have a branch to start with.

[I'll reorder your paragraphs a bit, but all your text is left]


>     For how long? "Eternity"? Or is this a meant to be a feature
>     branch that gets incorporated into the mainline at some time?
> 
> The hope/plan is to update the code from QtC 4.8 to master in the
> branch, and let more developers review.  Once approved, we'd like it
> to be part of QtC and not be maintained in a separate branch.

As Thiago already stated, such content should target 'master' branch.

There won't be any release from the 4.8 branch anymore, nor would in
the normal course of action any merges happen there, so effectively
any new content in 4.8 would just cause extra effort to merge down to
4.9/4.10/master, causing more work to handle all intermediate stages
than to directly jump to master.

Even if code is not directly compilable in master, interesting contents
often finds helping hands to update it once it is on gerrit.

>     How is this planned to be maintained? Will you do that, and the
>     mainline is not affected at all?
> 
> Because QtCreator does not maintain binary compatibility like the rest
> of Qt, maintenance is a burden, requiring changes for each new QtC
> version.  We'd like that to be taken over by The Qt Company,
> just as it is done for other plugins. 

Note that "being part of the Qt Creator" does not imply "being
maintained by the Qt Company". Being part of the Qt Creator sources
only means a high probability that the code remains updated and
compilable, and typically also working, as any changes to the core
will be more or less mechanically be applied everywhere. 

Other than that it's the usual bunch of options if you want a real
guarantee that it keeps working:
 (a) do it yourself,
 (b) find someone interested in the code doing it for you,
 (c) pay someone to be interested in the code doing it for you.

All those approaches are easier/cheaper if the code is in-tree,
as at least mechanical updates are applied "for free", but 
"drop and run" is, generally speaking, not an option.

> We expect it to be much less of a burden for the people making
> the changes and knowing why they were made.

That's indeed typically the case.

> Regards, Brett

Regards, Andre'
> 


More information about the Development mailing list