2:42 a.m.
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). What can/should I do to
include the otopi-1.8.1 build [2] in the 4.3 change queue?
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?
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).
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.
[1] https://gerrit.ovirt.org/#/q/I794426ec9212e0a023c3e5f158d0a88fc8e6842c
[2] https://gerrit.ovirt.org/98408
--
Didi
3: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
4: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
1947
days inactive
1947
days old
2 comments
2 participants
participants (2)
-
Barak Korren -
Yedidyah Bar David