On Thu, Sep 26, 2019 at 11:36:10AM +0200, Pierre-Yves Chibon wrote:
> Good Morning Everyone,


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?


Attachment: signature.asc
Description: PGP signature

devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Reply via email to