On Mon, 17 Oct 2016 11:16:22 +0200 Pavol Babincak <pbabinca@xxxxxxxxxx> wrote: > On 10/17/2016 06:46 AM, Tim Flink wrote: > > On Mon, 3 Oct 2016 13:50:33 -0600 > > Tim Flink <tflink@xxxxxxxxxx> wrote: > > > >> One of the features for Taskotron that we've been planning since > >> the beginning was a way for contributors to maintain their own > >> automated tasks/tests which would be run during a package's > >> lifecycle. > >> > >> I'm happy to say that we're almost to this milestone and wanted to > >> get some feedback from devel@ on the specifics of what we're > >> planning WRT where these automated tasks will be stored and the > >> execution modes that we're planning to support. Our current plan > >> is written up at: > >> > >> https://phab.qadevel.cloud.fedoraproject.org/w/taskotron/new_distgit_task_storage_proposal/ > >> > >> The hope is that by making it easier for contributors to write > >> automated tasks and making the model completely self-service and > >> convention drive, there will be a lot more automated checks for > >> packages than we currently have for Fedora. > >> > >> Please read through the wiki page I mentioned above and give us > >> feedback on whether what we're planning to implement is going to be > >> useful or if there are areas of the plan which could be improved. > > > > Several folks have brought up concerns (off list) about our plan to > > use sub-directories inside the rpms/ dist-git repos instead of > > separate namespaces. The possibility of using namespaces (which are > > effectively separate git repositories) did come up but I want to > > make sure this discussion topic comes up in a more obvious fashion. > > > > As I understand it, the primary concern is around having non-rpm > > stuff in the repo and the commit history. I'm aware of two reasons > > for that concern: > > > > - Red Hat uses separate repos internally to hold tests for RHEL > > packages and putting checks/tests into the rpm repo will make it > > more painful farther down the road for RHEL package > > maintainers. > > I'd like to describe Red Hat's dist-git structure/design. There are > two relevant namespaces: > > - rpms/* for regular repositories used for building rpms > - tests/* for storing tests > > rpms repositories have product branches similarly to Fedora's > dist-git. > > Whereas tests repositories have only master branch. There is no > global policy how tests repositories are structured and what goes in. > Everything is on QA group who manages set of repositories. One of the differences in Fedora is that I expect most check/test contributions will come from package maintainers instead of dedicated QA folks. At this time, there just aren't enough available person hours among the Fedora QA folks to match the number of packages and components which are in Fedora. > From workflow point of view: > - for every rpms/ repository there is tests/ repository created > automatically. > - if there are any special operations done on rpms/ repository tests/ > repository is also considered here. E.g. removal, deprecation, etc. > - rhpkg (preferred tool for working with dist-git repos - corresponds > with fedpkg) has separate command to checkout tests - "rhpkg tests". > This would roughly correspond to "fedpkg co tests/foo". > > > Side note about the tooling: > - dist-git repository management on server side started with the same > code base. So as long as Fedora doesn't diverge too much (e.g. pagure > isn't considered internally yet) porting these changes can be fairly > trivial. > > - rhpkg, similarly to fedpkg gets majority of the code from pyrpkg > library. If it turns out tests/ support makes a sense in other client > tools pyrpkg may get this code thus get this feature easily. (I'm > CCing cqi who is working on rhpkg/rpkg/fedpkg code and may provide > more insight here). Is that code in rhpkg or rpkg (the parent of both rhpkg and fedpkg, assuming that I got the name right)? > > - Adding the checks/tests into the same repo increases the size of > > the repo and could end up requiring more effort to search > > through those commits for a specific change > > > > - If there are other concerns, feel free to bring them up. > > > > We chose the directory-in-dist-git option because it seems like the > > better, more simple option. It requires fewer steps to get > > checks/tests pushed, no extra tooling modification, makes the > > checks/tests easier to find and would make for a less complex > > system overall. > > > > That being said, I don't maintain many packages and I'm not going to > > pretend that I know what's best for maintainers. So long as the end > > system is consistent, easy to use, makes sense and is feasible to > > complete with resources we have, I don't have a strong opinion on > > whether we use directories or namespaces to hold checks/tests. > > > > Which brings me to the question that I'd like to get some feedback > > on: would it be preferable to store checks/tests within directories > > of existing dist-git repos or create a new namespace to store > > checks/tests and fiddle around with tooling etc. to hide some of > > the complexity that may bring? > > > > I'm wondering if you can estimate what amount of the work is needed > here which excuses mixing up content in the design. I'm not sure that I understand what you're asking here so I'll rephrase what I think you're asking - please correct anything I've mixed up. "How much extra work/complexity for Fedora maintainers is enough to justify doing something different from what RHEL maintainers are already doing?" Unfortunately, I don't have a wonderfully objective, short answer to this but I'll attempt a longer-winded answer. To me, one of the most applicable differences between RHEL and Fedora is that as a community project, there is not really a way to make contributors do something. If we had an army of dedicated QA folks who were doing most of the package-level testing, it would make more sense to separate checks/tests and rpm data (spec files, patches etc.). Since we don't have that kind of an army in Fedora, it will be package maintainers who are writing most of the automated jobs for Fedora packages. The more steps and levels of indirection we add to the process of contributing automated checks/tests for Fedora packages, the higher the barrier to entry will be. I'm under the impression that most packagers are plenty busy as it is and raising the barrier to entry for contributing checks/tests at all will reduce the number of checks/tests contributed. Rephrasing my answer as a question: how many package level checks/tests in Fedora are acceptable to lose in exchange for closer alignment with downstream projects? I don't know of a way to empirically answer any of those questions which is why I'm asking for feedback here from people who probably have a better idea of what level of annoyance they're willing to tolerate than I do. I'm hoping to hear from both folks who deal with both Fedora and downstream in addition to folks who don't work with downstream. Tim
Attachment:
pgpI4xx62COQJ.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
