On Thu, Sep 26, 2019 at 11:36:10AM +0200, Pierre-Yves Chibon wrote: > Good Morning Everyone, ...snip... So, a few thoughts in general on the thread and ideas... I think it might be helpfull for us to come up with some personas? I know that kind of thing seems silly a lot of the time, but I think we have some pretty clear ones and it would help us come up with a workflow that could work for much of our maintainers instead of just one group. ie, for example I think we have a group of folks who maintain a very small number of packages. These folks might be upstream maintaining their software as a fedora package or just someone who uses / cares for it. They want something simple where they can update packages/modules from upstream releases on an optional number of releases using just a tarball or other release artifacts. Then there's people who maintain 100's or many hundreds of packages, usually in a stack (perl, ruby, node, etc). They want the ability to update things but they also need to make big changes accross their collection of packages for improvments or changes in the ecosystem. There's people who maintain a application and it's deps who may need/want to update/test things in a bundle, etc. There's people who care about EPEL and want to follow the Fedora branches, but only if they don't make major changes. And likely other cases I haven't thought of in a few seconds of pondering, but we should definitely consider in our design. I think it's pretty clear that the "Everything is a PR" work flow doesn't work for everyone. As well as the "Sources are a git repo". So, I think a ideal setup would allow people to make choices and switch between them. Of course I don't think we should just allow everything, but we should have path's that cover a large group and choices only where we have to to accomodate the needs of the different groups. I like the idea of leveraging tags as a way to provide information to our new system what to build and test. Allowing commits without builds/testing would help the ecosystem user make a bunch of changes, then they could tag that what they have is ready to build/test/make an update out of, while a user doing just small updates could tag on every commit if they wanted to. Perhaps we could also determine all the information we want in tags and design it such that a web application, a cli application or even a user who understood the format could just git tag and enter the needed information. This would allow groups using each of those to all work the same way as they choose. If we went crazy far down this road: what if all our information is in tags? who can commit, whois watching, etc... but then we would have to hate ourselves enough to do gpg signed commits to make sure who was who. I think we all agree we need to handle release and changelogs in an automated way that lets commits/PR's be more generally useful. I also think we have not really any good tools for maintainers to know important things like: "what is the full list of everything my package depends on" or "Of all the things my package depends on, what hasn't been updated in X years" or "What media is my package on?" which we have wanted for ages. Not sure if that fits in here, but it would sure be nice to have, and it would be required for any of the 'rebuild things that depend on my package when I change it'. I'm not sure how to handle the dychomoty between having different spec files for each release and wanting to maintain just one spec that has a bunch of crazy conditionals in it. Even thought I do this too, I think we need a workflow that discourages this somehow. Anyhow, I think it might be worth making some personas and trying to map out how tags could contain the information we might want and how that would look? kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
