9:33 a.m.
On Mon, 11 Mar 2019 at 08:43, Yedidyah Bar David <didi(a)redhat.com> wrote:
Hi all,
I branched yesterday otopi-1.8 to be used for ovirt-4.3, and forgot to
patch stdci accordingly. Now pushed the patch [1] (to both master and
otopi-1.8 - I realize I do not need it in master, but hopefully this
will help me remember patching it in 4.4).
The release branches syntax was designed to allow you to do that.
What can/should I do to
include the otopi-1.8.1 build [2] in the 4.3 change queue?
Either:
Merge this patch -> https://gerrit.ovirt.org/98408
And then merge a build patch to the 1.8 branch
Or:
Merge a patch making the master branch submit to the 4.3 CQ as well on to
of the build patch and then revert it.
Generally the CQ is a CI construct - it does not care about "build"
patches, from its POV all patches are equal and it just cares about the
lates patch in any given relevant branch.
We've suggested to make an "official build" CQ in the past that would only
take in tagged patches and construct the "official" releases, there id not
seem to be any eager adoption of this idea.
And, related to this, some ideas about how to make stdci more useful
for mere developers:
1. Make the change-queue post comments in gerrit patches once it has a
result (patch passed change queue X, failed, something else?). I (as
always) prefer a bit more information (e.g. a few more comments that
might not be that interesting) than not enough (current). We can
always refine later. IIRC this was already discussed in the past - any
update?
Here is the old ticket about this:
https://ovirt-jira.atlassian.net/browse/OVIRT-1447
This idea is about as old as CQ itself...
2. Make the current comment "This change was successfully
submitted to
the change queue(s) for system testing." more informative - include
names of change queues and links to relevant pages (builds? not sure,
I do not know enough CI).
That message is sent from the V1 "standard-enqueu" job, and is irrelevant
for V2 projects. It is only sent BECAUSE there is a separate job that can
fail separately.
In V2 the CQ submission is done by the same "*-on-merge" job that also runs
"check-merged" and build the artifacts if needed. The CQ submission step
could be seen in the blue ocean screen for the job.
The CQ core code itself has quite an elaborate status notification hooking
mechanism that can be made to send a rather detailed information about the
processing stages the patch goes through in the CQ, but to make that send
notifications, someone would need to write some code. There is some
shortage of developers that are familiar with the CQ code ATM.
3. As a side note, I realize that the option names were made
case-insensitive and ignore whitespace/dashes/underscores in order to
not impose a certain style on the many different projects/maintainers
and let them use what they find best for their project. I personally
think this was a mistake. If you have to make a choice when naming
something, and have a feeling that your opinion might cause
noise/objections/etc. in the future, make a quick poll asking what
people prefer, and then pick a single name. Having several (many)
different names for things makes it much harder later on to _find_
them. It might be too late now to change, because people might already
picked different names in practice and we do not want to break their
stuff, and that's a pity. But next time, be opinionated, or ask
beforehand - not keep the choice. Most computer languages and
libraries have single unique names for things, for a reason.
My view on the subject is different. Almost all languages have some styling
leeway and leave some decisions to project developers or code linting tool
authors. Many heavily used languages are case insensitive for example.
Notable examples include SQL and HTML. In the realm of configuration files
this quite seems to be the norm. In short, I think styling should be
enforced by an external tool and not the core parser or compiler.
I think having stuff "just work" instead of failing transparently because
you wrote "-" instead of "_" is more important then being grep
friendly. In
this case writing the configuration is more common them grepping for it
IMO. And also making an insensitive version of grep, or otherwise, a tool
that would quickly convert a file to a canonical version should be easy
enough.
[1]
https://gerrit.ovirt.org/#/q/I794426ec9212e0a023c3e5f158d0a88fc8e6842c
[2] https://gerrit.ovirt.org/98408
--
Didi
_______________________________________________
Infra mailing list -- infra(a)ovirt.org
To unsubscribe send an email to infra-leave(a)ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/infra@ovirt.org/message/S2GLOLZIOAL...
--
Barak Korren
RHV DevOps team , RHCE, RHCi
Red Hat EMEA
redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted