[SSSD] [sssd PR#531][comment] Add the needed machinery to have automated builds for our COPR repos

2018-05-15 Thread fidencio
  URL: https://github.com/SSSD/sssd/pull/531
Title: #531: Add the needed machinery to have automated builds for our COPR 
repos

fidencio commented:
"""
master:
 e551413
 4568d68
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/531#issuecomment-389379978
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org


[SSSD] [sssd PR#531][comment] Add the needed machinery to have automated builds for our COPR repos

2018-05-15 Thread jhrozek
  URL: https://github.com/SSSD/sssd/pull/531
Title: #531: Add the needed machinery to have automated builds for our COPR 
repos

jhrozek commented:
"""
ack if we continuously build only master.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/531#issuecomment-389140980
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org


[SSSD] [sssd PR#531][comment] Add the needed machinery to have automated builds for our COPR repos

2018-04-24 Thread fidencio
  URL: https://github.com/SSSD/sssd/pull/531
Title: #531: Add the needed machinery to have automated builds for our COPR 
repos

fidencio commented:
"""
Is there something missing in this PR? Can we have it merged?
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/531#issuecomment-384168586
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org


[SSSD] [sssd PR#531][comment] Add the needed machinery to have automated builds for our COPR repos

2018-03-13 Thread fidencio
  URL: https://github.com/SSSD/sssd/pull/531
Title: #531: Add the needed machinery to have automated builds for our COPR 
repos

fidencio commented:
"""
> The COPR repos should be at least usable and currently the git HEAD of our 
> branches might or might not be usable in some aspects -- for example AD 
> provider or IPA provider are not tested at all upstream. The integration 
> tests we have test only a small subset of the functionality and for a lot of 
> functionality we rely on greentea tests. Prior to the release of 1.16.1 there 
> was quite a few bugs (3594 for example, I remember that one because I was 
> working on it) which were only revealed by the greentea tests.

>Until we have commit gating with all the available tests, we can't be sure 
>that everything works. And we only do a release at the point where our 
>downstream tests are also passing. After that, we tag the release and the 
>release is the sssd upstream saying "this bundle of commits is known to work 
>well together".

Okay, I agree with that for branches that are not the master one.

>I don't think there is any harm in having "sssd-1-13-rolling" branch and 
>"sssd-1-16-rolling" in addition to building the releases in COPR, but I don't 
>think having the git HEAD as the default without warning is a good idea until 
>we drastically improve our coverage.

Okay, here I can see I had a wrong perception of the COPR usage for SSSD team. 
My understanding was that sssd-1-13 COPR was **exactly** what you're suggesting 
by "sssd-1-13-rolling" and then if someone wants something more stable they 
would go for the release.

Having sssd-1-13, sssd-1-13-rolling, sssd-1-13 release ... It does sound like a 
quite big overkill IMHO.

So, summing up ... I'm fine about enabling this for **master** only and then 
I'm open to discuss some idea to automate the way 1.16 and 1.13 would be 
generated.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/531#issuecomment-372714239
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org


[SSSD] [sssd PR#531][comment] Add the needed machinery to have automated builds for our COPR repos

2018-03-13 Thread jhrozek
  URL: https://github.com/SSSD/sssd/pull/531
Title: #531: Add the needed machinery to have automated builds for our COPR 
repos

jhrozek commented:
"""
The COPR repos should be at least usable and currently the git HEAD of our 
branches might or might not be usable in some aspects -- for example AD 
provider or IPA provider are not tested at all upstream. The integration tests 
we have test only a small subset of the functionality and for a lot of 
functionality we rely on greentea tests. Prior to the release of 1.16.1 there 
was quite a few bugs (3594 for example, I remember that one because I was 
working on it) which were only revealed by the greentea tests.

Until we have commit gating with all the available tests, we can't be sure that 
everything works. And we only do a release at the point where our downstream 
tests are also passing. After that, we tag the release and the release is the 
sssd upstream saying "this bundle of commits is known to work well together".

I don't think there is any harm in having "sssd-1-13-rolling" branch and 
"sssd-1-16-rolling" in addition to building the releases in COPR, but I don't 
think having the git HEAD as the default without warning is a good idea until 
we drastically improve our coverage. 

About testing the sssd-1-13 branch before a release, we need to do that before 
the release IMO. There are some downstream tests that would fail because they 
might check for functionality or regressions not present in 1.13 but we should 
at least run all the tests with 1.13.4 and 1.13.5 prior to 1.13 release and 
compare regressions. This work is not related to COPR, but in general, I don't 
think we should release upstream without testing it.

About the smaller releases, I agree. I think there we need to improve our 
failure detection and stability of tests, because currently we check the 
failures downstream more or less manually, but I would also like to have montly 
or bi-monhly releases.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/531#issuecomment-372610526
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org


[SSSD] [sssd PR#531][comment] Add the needed machinery to have automated builds for our COPR repos

2018-03-12 Thread fidencio
  URL: https://github.com/SSSD/sssd/pull/531
Title: #531: Add the needed machinery to have automated builds for our COPR 
repos

fidencio commented:
"""
> I'm fine with this plan for master, but do you think it's wise with our level 
> of testing to build packages after every commit?

Maybe I should be more conservative (and here I'm quite opened to be convinced 
to do so), but if someone decides to use sssd-1-13 or sssd-master **copr** they 
pretty much know what they signed for.

Those repos are **not** supposed to be delivered to customers, at all, but to 
help people help us with early test of a release (and here, again, they'd know 
what they signed up for).

Considering we don't have this for every commit, what would be your idea? What 
kind of content would be okay enough to trigger a update in a non supported 
copr repo? IMO ... if we don't do this for every commit (but do it monthly, 
let's say), I'd prefer to stick to do smaller releases, way more often and then 
make the copr repos something that's not even needed.

> We also try to check the greentea tests at least before releases to make sure 
> no regressions are introduced and sometimes this takes quite a bit of time 
> between the test breaks and the fix is introduced.

Yep, but here we're talking about releases. A copr repo is not an official 
release and should not be treated as so. Again, I do believe that people using 
it know what they're signing up for (and I may be wrong here :-))

> So I would vote to only use this mechanism for the master branch. If you 
> think there are users of the other branches for every commit, then I would 
> prefer to have a separate branch where we build only the releases and a 
> separate git-tracking branch that would be built automatically.

I don't see the point on not having sssd-1-13 releases for instance. Correct me 
if I'm mistaken, but I don't think this branch is currently tested apart from 
integration/unit tests when something new is pushed there ... by providing the 
copr repo someone would at least be able to give it a try (and it's totally for 
free for us).

Although, I'm not in the project for time enough to properly understand your 
concerns.
What are the problems you see that may hit us in the future in case we have the 
copr repos updated on every commit on those branches ... considering that 
releases will still happen on those and the releases are the "stable" version?

> btw now I wonder if the only-releases-go-here branch could also be automated 
> in the sense that a build would only happen in the branch when a new tag is 
> added..

I'm not sure how easy it would be, but I can spend some time investigating it.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/531#issuecomment-372472945
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org


[SSSD] [sssd PR#531][comment] Add the needed machinery to have automated builds for our COPR repos

2018-03-12 Thread jhrozek
  URL: https://github.com/SSSD/sssd/pull/531
Title: #531: Add the needed machinery to have automated builds for our COPR 
repos

jhrozek commented:
"""
I'm fine with this plan for master, but do you think it's wise with our level 
of testing to build packages after every commit? We also try to check the 
greentea tests at least before releases to make sure no regressions are 
introduced and sometimes this takes quite a bit of time between the test breaks 
and the fix is introduced.

So I would vote to only use this mechanism for the master branch. If you think 
there are users of the other branches for every commit, then I would prefer to 
have a separate branch where we build only the releases and a separate 
git-tracking branch that would be built automatically.

btw now I wonder if the only-releases-go-here branch could also be automated in 
the sense that a build would only happen in the branch when a new tag is added..
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/531#issuecomment-372442416
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org


[SSSD] [sssd PR#531][comment] Add the needed machinery to have automated builds for our COPR repos

2018-03-09 Thread fidencio
  URL: https://github.com/SSSD/sssd/pull/531
Title: #531: Add the needed machinery to have automated builds for our COPR 
repos

fidencio commented:
"""
CI: http://${abc}/logs/job/86/51/summary.html
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/531#issuecomment-371893328
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org