On Mon, 11 Mar 2019 at 08:43, Yedidyah Bar David <d...@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@ovirt.org > To unsubscribe send an email to infra-le...@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/S2GLOLZIOALY7U7IITX6SB6W33S4SHJ3/ > -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
_______________________________________________ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-le...@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/T2KPLK22Q3Z37GKFLEEDBKNELPKUY2F2/
