Tobias Frost <[email protected]> writes: >> > We usually start using that informatin when we've determined that >> > specific person became inactive or unreachable, and then need to >> > determine which packages might be affected. Upload history helps to see >> > past activity, but it does not reliably answer the question "which >> > packages do we need to look at because this person was involved?" >> >> Why not? I think commit and upload history is a good indicator. >> >> Commit and upload history seems to me be the real indicator of where >> actually work happens (or not happens). Isn't this information >> available in UDD or some similar resource? > > Activity data is certainly useful to assess where work has happened. The > question from the MIA perspective is slightly different: once a person > has been determined inactive, how do we obtain a reliable and complete > list of packages that may require follow-up action because of that > person’s involvement? > > Do you have some concrete query in mind that you could share with me, > which would tell (quickly and with accuracy) that someone stopped > working on a package and we need to tell someone, e.g a team? What other > resources do you think could help?
I think I'm missing some piece of the context here, because in my mind the logic is simple: - MIA team get some indication that a person may be MIA, and then actually confirm that the person stopped working X months ago or similar (which could involve a couple of round-trips of personal e-mails). - Review everything the MIA person has actually done. For packaging work, the complete list of commits & uploads is a sufficient, isn't it? For non-packaging work I wouldn't know where to look. - Take action on the review, notifying relevant teams and/or orphan packages that doesn't have any remaining owner. How do the Uploaders field help you? I know little about this and do not feel particulary qualified to comment on the MIA team workflow. If it works for the MIA team and critically depends on the Uploaders field, then I wouldn't want to challenge your workflow. Then it becomes the job of the rest of the project to evaluate if the cost of requiring the Uploaders field outweight the advantages of having the MIA team use their current workflow. Maybe discussing a new MIA workflow, not based on Uploaders, will help here, and you can evaluate if that new workflow would be better or worse than your current setup. >> > in other words, the information in the Uploaders field is less about >> > determining activity and more about enabling action once inactivity has >> > been established. >> > >> > If team membership is not clearly documented, we cannot easily >> > determine which team should be contacted when someone goes missing. In >> > practice, that would mean teams would need to notice emeritus/removed >> > cases themselves and act accordingly. For DMs and DCs, we do not even >> > have comparable notifications. >> > >> > The Uploaders field is not perfect, but it provides a simple and >> > queryable mapping from person to packages, which is exactly what we need >> > when starting to clean up after a missing person. >> >> I don't understand this part. What is the cleaning up action you are >> thinking of? Is it removing the MIA person from the Uploaders: fields? >> >> What else is there to do when someone disappears? > > Orphaning and asking to remove persons from the uploader is possibly the > effect that has the most visibliy to the project. If the package is team-maintained and doesn't have a Uploaders field, no new upload will be necessary. If the person is in the Uploaders field, removing them would be good, but this is just extra work if the team takes care of the package properly. That work may be saved by making Uploaders optional. Orphaning a package when the person is in Maintainer will still be necessary though, but I think that is unrelated to the Uploaders field. > From the MIA side, however, that cost does not disappear, it shifts. > Instead of updating a structured field at the time of change, we would > need to reconstruct person -> package relationships later from activity > data when cleanup is required. Right. I'd argue that you need that anyway. > Maintaining the Uploaders field is comparatively cheap and distributed: > it is updated when work is already happening. Here I disagree, and this is the reason for all of this. I believe having a required Uploaders field is a really costly matter, both technically (there is no consensus on how to update the field, see the feedback from various teams in Debian that aren't really using this field for anything but initial packager) and socially (it perpetuate the single-maintainer ownership model where others are not encouraged or feel entitled to touch a package). > Explicit and queryable person -> package associations are one of the > few structured signals we currently have at the package level. Hmm. Could someone design a UDD query that give you that association, but based on commit & uploader activity instead? I think such an association would be more accurate than looking at Uploaders fields. You seem to be coming back to the person->package association as an important part, and while I believe this is a social mistake -- let's team-maintain all packages instead -- I understand this association is needed if you start from a single-person maintainer assumption. > The more systematic inactivity workflow discussed at DebConf > (I've nicknamed it "MIA 2.0" earlier) outlines a possible activity-based > model, but it remains conceptual and is not operational today. Interesting, do you have a URL? /Simon
signature.asc
Description: PGP signature
