Please, create the following new repositories in the tests namespace:
The main admin should be for all of them "praiskup". Thanks.
Metadata Update from @pingou: - Issue assigned to pingou
I'm not going to make these right now, the tests was discussed as a place where test would be shared between different packages, not as a place where packages could place their tests (these should be in dist-git).
tests
So this requires more discussion before being processed.
OK, understood. We need to make the expectations clear soon as it is blocking more tests to be ported. To move things forward, could you please create a new repo for selinux?
https://pagure.io/fedora-infrastructure/issue/6699
This is to be used for all selinux userspace components. Thanks.
It was discussed before though. I want basically one branch in ./tests repositories for these reasons: - everything is on one place, for all fedora branches, epel/rhel packages (and e.g. scls, for e.g. PostgreSQL packages -- since this is how our internal beaker tests work) - we want to publish RHEL tests, starting from scratch and maintaining on two places is not in my capacity - I want to be able to grant FAS people (not necessarily fedora packagers) to commit, concretely Red Hat QE people who take care of RHEL tests
./tests
Reading again, the gc package should be dropped from the list. I'm not the main admin so @rdieter should probably decide how to handle CI there.
gc
I want basically one branch in ./tests repositories for these reasons: - everything is on one place, for all fedora branches, epel/rhel packages (and e.g. scls, for e.g. PostgreSQL packages -- since this is how our internal beaker tests work)
Same things is the tests are stored in the git repository of the package. How things work internally is of very limited interest in Fedora and this process isn't meant to duplicate what is being done internally but setup a new way of working on packages.
we want to publish RHEL tests, starting from scratch and maintaining on two places is not in my capacity
I don't understand that, there is only one place where tests are, that's the git repository on dist-git.
I want to be able to grant FAS people (not necessarily fedora packagers) to commit, concretely Red Hat QE people who take care of RHEL tests
Projects on the tests namespace on Fedora's dist-git are still currently restricted to packagers only, we're working on this and hopefully we'll have some news on this sometime soon. So that point doesn't make a difference :)
The code is in each branch, which was never needed for these tests.
Projects on the tests namespace on Fedora's dist-git are still currently restricted to packagers only, we're working on this and hopefully we'll have some news on this sometime soon.
Thanks for looking at this. It is non problem, I can wait for it. Do we have a ticket?
That's just like the spec file though, no?
Tests are much, much larger then spec file, usually. So backports are not trivial.
Three's usually much more frequent cadence of commits, and that's not something random package administrator wants to see in git-log (there are some flames about baking git-log to %changelog, btw.).
How things work internally is of very limited interest in Fedora and this process isn't meant to duplicate what is being done internally but setup a new way of working on packages.
Well, I need to have similar workflow, otherwise it goes easily beyond my capacity. Maintaining completely different set of tests is not something I'm interested in. Maybe the tests/ is not the answer and we should went to github or so, but I really need to find a way how to easily cooperate with our QA to share the interests....
tests/
From Fedora POV of course we want to have as much people as possible interested in doing the QA work, and taking care of the tests -- which is exactly what I fight for.
that's not something random package administrator wants to see in git-log
I have the opposite opinion, I'd be curious to see how tests are changing/being changed for the package I maintain. This is just proving that the point is not to discuss opinions.
here are some flames about baking git-log to %changelog, btw
The discussion is more how to rework our changelog and release-notes. There seems to be agreement that git commits is not the solution for this.
Maintaining completely different set of tests
This really confuses me, what do you mean about completely different set of tests? All I've seen so far are tests that are basically set once for all branches, they are basic functionality tests. They may/will likely expand but I don't see how they would be entirely different and if they are how they would require maintenance (since the package shouldn't change withing a branch in a way that would require these tests to be adjusted).
but I really need to find a way how to easily cooperate with our QA to share the interests....
Granting these people access on the repository and relying on pull-request until then should address this, doesn't it?
I have the opposite opinion, I'd be curious to see how tests are changing/being changed for the package I maintain.
Ok, I agree with you that this is highly about personal taste. I don't want to change your interests ... I consider the additional changes in package's dist-git rather noisy, if they are not related to the package build itself.
This is just proving that the point is not to discuss opinions.
This is not parsed :-) maybe the thread goes to be switched against me :-) but I have only good intentions here.
Wow, you are much more optimistic , since I don't see the consensus there ... but I agree that git-log generator won't work for everyone.
This really confuses me, what do you mean about completely different set of tests? All I've seen so far are tests that are basically set once for all branches, they are basic functionality tests.
The tests we had so far are much more than "basic" tests. By completely different sets of tests I mean tests which doesn't share anything with each other, so multiple people deal with the same issues on multiple places.
They may/will likely expand but I don't see how they would be entirely different and if they are how they would require maintenance (since the package shouldn't change withing a branch in a way that would require these tests to be adjusted).
Yes, it is personal view -- and I mostly maintain packages which are core packages, and thus are also maintained in RHEL (so they have pretty large amount of existing test-cases already).
I think this is a good topic for a broader discussion on the fedora devel list. I've sent an email there with the reference to this issue.
Wasn't also one reason to not just share tests between packages, but to have different access controls - e.g. to have different contributors. Also, I see this as a good place if tests are to be used on multiple branches, though one could also feasibly put stuff into master for those cases.
Based on the latest discussions, Pierre, could you please enable these repositories and unblok porting tests? Thanks.
My opinion hasn't changed and I don't think we should do it but the repos have been created.
Metadata Update from @pingou: - Issue close_status updated to: Fixed
Thank you, Pierre.
Login to comment on this ticket.