On Mon, Mar 11, 2019 at 9:33 AM Barak Korren <bkorren@redhat.com> wrote:
On Mon, 11 Mar 2019 at 08:43, Yedidyah Bar David <didi@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@ovirt.org To unsubscribe send an email to infra-leave@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/S2GLOLZIOALY7U...
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
-- Didi