[SSSD] Re: Github labels: Suggestion
On 8 Mar 2018, at 10:33, Fabiano Fidêncio <fidencio(a)redhat.com>
wrote:
People,
I've noticed that I'm getting a little bit lost with github and the
way SSSD has its tags organized there.
As it may actually affect other people (and in case it does not, let's
just skip the following suggestion) ... I'd like to suggest the
following tags to the project:
- Accepted: We already have it;
- Rejected: We already have it.
- Tests needed: This one can either replace the "Changes Requested"
(in case it's split in a few different tags) or be used together ...
but the idea is to identify that tests are missing from a PR without
going through the whole discussions happening there;
What do you propose would be the action after tests needed? Should it be a follow up PR, a
ticket for the project, a ticket for downstream..?
My worry about not supplying tests along with PRs is that the tests will never be
supplied..at least not in upstream..
- Depends on (or something similar): This one can either replace the
"Changes Requested" (in case it's split in a few different tags) or be
used together ... but the idea is to identify that we depend on
somework that still has to be done (either another PR, ticket or
something else that has to be implemented). Mind that I'm not sure
whether we'd be able to simply add a field saying what the PR depends
on …
I think this makes sense. At least for a casual observer it would be clear that there is
no work needed on this PR.
- Postponed/Deferred: We have something similar for 2.0, but would be
nice to have a way to clearly see in which release we're going to take
a look into a specific PR without having to dig in the discussions.
Here we could also have 1.16.1, 1.16.2, 2.0, …
Tags are cheap, we can even have a postponed/$version. I guess even depends/$PR might be
OK as long as we only had a handful of dependecies.
- Reworked: Although just removing the "Changes Requested" label is
fine, maybe having a tag explicitly saying that something was Reworked
would be a clean way to differentiate between new PRs and PRs which
have been through a review already …
I don’t know how this tag would be used, could you give me an example, please?
Does the suggestion make sense? In case we have an agreement about
this topic, may I re-tag our PRs and start using those new tags from
new PRs?
Another tag I was thinking of was “passes downstream tests”. With the amount of time our
downstream tests take, I’m not even sure how to integrate them with the usual github flow
like travis or centos CI use. So I was thinking about a bot that would nightly scan PRs
that have neither “pass” or “fail” tag, bundle those up in an RPM, run the nightly tests
and report back using a tag.
Best Regards,
--
Fabiano Fidêncio
_______________________________________________
sssd-devel mailing list -- sssd-devel(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-leave(a)lists.fedorahosted.org