On Sun, Feb 5, 2017 at 11:33 AM, Martin Sivak <msivak@redhat.com> wrote:
>> A repo where I do not have commit rights means I can't take full responsibility.
>> A repo that is not atomically synchronized with my sources means I
>> can't take full responsibility.
>
> Having said that, I would be perfectly fine with a single repository
> that tracks the release configuration, but only if it also held the
> git repository link and hash/branch name that is supposed to be
> released. It would be in some way a "distgit repo". Something like
> Sandro has for builds.
>
> [ovirt-4.0.x-ci]
> git://gerrit.ovirt.org/project.git#ovirt-4.0.x
> git://gerrit.ovirt.org/project2.git#v4.0.x
> git://github.com/Me/repo#master
>
> [ovirt-4.0.6]
> git://gerrit.ovirt.org/project.git#ovirt-4.0.6
> git://gerrit.ovirt.org/project2.git#v4.0.6
> http://github.com/Me/repo/releases/x.y.z.zip
>
> Any release would then be reviewed by the CI team and that would be
> fine for me. It would allow any branch name or versioning convention
> and would not pollute the sources. It would also be gerrit agnostic.

Well said!

May pain points with jenkins project:

- No documentation
- The format is not stable, each time you edit the format is different
- No way to test changes, only infra guys can test changes, sometimes
  even infra guys cannot test changes and they simply merge them
  for testing
- The project format is full of duplication
- No commit right, cannot be responsible for something I cannot change

Compare with travis:

- Everting defined in *my* project in .travis.yml
- Configuration format is well documented
  https://docs.travis-ci.com/
- Configuration format is well designed, can do lot of work with very
  little configuration
  For example - this yaml define matrix of 3 builds:
  https://github.com/oVirt/vdsm/blob/master/.travis.yml
- Easy to test changes before merging (push to your fork on github)
- Very nice web ui, e.g.
  https://travis-ci.org/oVirt/vdsm/builds/198571421
  https://travis-ci.org/oVirt/vdsm/jobs/198571422

Nir

>
> Martin
>
>
> On Sun, Feb 5, 2017 at 10:17 AM, Martin Sivak <msivak@redhat.com> wrote:
>> Hi,
>>
>>> The fact that this is specified in the 'jenkins' repo **does not place
>>> this outside the maintainers` responsibility**.
>>
>> A repo where I do not have commit rights means I can't take full responsibility.
>> A repo that is not atomically synchronized with my sources means I
>> can't take full responsibility.
>>
>>> We actually have an initiative to move this information to the project
>>> repos. I've started with asking on devel list about how to specify
>>> this as part of Standard-CI [1]. But have received little topical
>>> response so far.
>>> [1]: http://lists.ovirt.org/pipermail/devel/2017-January/029161.html
>>
>> You've got enough responses already to propose a different schema than
>> fixed branch names. Just give us a config file. Seriously, stop
>> reinventing the wheel and take a look at how others are doing it
>> (distgit, travis, tito, ...).
>>
>> Martin
>>
>>>
>>> --
>>> Barak Korren
>>> bkorren@redhat.com
>>> RHCE, RHCi, RHV-DevOps Team
>>> https://ifireball.wordpress.com/
>>> _______________________________________________
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel