11:28 a.m.
On Mon, Mar 11, 2019 at 9:33 AM Barak Korren <bkorren(a)redhat.com> wrote:
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.
Understood.
>
> 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
It was already merged, to master, before I branched otopi-1.8
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.
Both are a bit ugly :-(
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.
Understood.
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.
Well, so I can give up as well, right?
The patches in [1] should be enough to trigger CQ, if we only care
about branch heads in CI...
> 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...
Obviously. Well, I'll be patient, seems like it's more-or-less in-progress...
>
> 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.
How much work would it be to create an initial version that will "send
everything" (be somewhat spammy, etc.)? If people then care enough it
will be easier to refine. I guess. Hope, at least...
>
> 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.
I think almost every developer that wants to write something for the
first (few) time(s), first searches for it to find examples, then
writes.
(That said, perhaps the (good!) CI docs should be amended to include
one or a few complete examples of conf files. This will definitely
help a lot, 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.
The specific reason I now sent this was that I wanted to see real
examples of 'release_branches' in existing projects. Searching google
for relevant items was a bit hard. Of course I can come up with a
script (which will be a little bit too complicated for typing in every
time I want to use it, so would really need to be a script) that greps
stuff on all the git repos I happen to have cloned to my laptop, but
it could have been (and should have been, IMHO,) easier.
>
> [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
--
Didi