On 11/07/07 at 10:20 +0200, Stefano Zacchiroli wrote: > > (1) the list should move to a text file in a VCS. For example, we could > > use a special directory in the collab-maint alioth project, or simply a > > repository writable by all DDs on svn.d.o. This would improve the way > > history is kept too. > > I fail to see the advantage of this, especially wrt the two problems > above. The wiki is easier to access than a VCS (you don't have to > checkout) and it already handles history, I don't think full-fledged > history management for the LowThresholdNMU page is something we actually > need. I can't find how I can get the full history of LowThresholdNMU, which could be a problem in case of abuse. Another problem is that having a complex format will make syntax errors easy, and it would be better to be able to validate the changes immediately. So I thought of a VCS with the list, and a parser script. But I have nothing against staying with the wiki for now, and we could always switch later if the wiki becomes a problem. > > (2) the list should be machine-readable. We could use the following > > format: > > Agreed, and I like the format you propose. > > Why can't we simply change the wiki page to match that format? The wiki > page won't be more error prone than a VCS file using the same format. > What we need to achieve this is just a volunteer which reviews the > current page and converts the current human-readable sentences in > machine-readable strings matching your format. Mmmh, maybe we could just convert all the "easy" entries (those with "all packages" with no restriction) and let the developers convert the other ones. But in all cases, it would be better to write a parser first, just to make sure the format is easy to parse, and we aren't losing important information or making it too hard to write entries with that format. > The only issue I see with the wiki is security, as anyone can currently > edit pages just after the registration, but for the page we are > discussing it won't be worst than the present situation. > > > (3) make the state visible on the PTS (see #429883). For each package, > > we could have an icon indicating if the package is NMU-friendly or not. > > All packages would have an icon, so having the "NMU-hostile" icon by > > default could help maintainers remember to add themselves to the list. > > Agreed, this can be done even in the current state. The PTS can download > the raw version of the page, consider only the lines that match your > format and ignore the remaining stuff. Ack > Besides, I think we can still do more to improve visibility, as neither > the wiki solution, nor the VCS based one would increase it above the > current status. I would like to see LowThresholdNMU mentioned in the > developer's reference (a quick check I made today shown that it's not > there, but I may be wrong), anyone up to writing a section and submit a > patch? We should probably defer that until the PTS icons are implemented, so we can document the final state. > > Is anyone interested in working on that? I will have problems finding > > the time in the near future > > I'm willing to patch the PTS for this, assuming there's an agreement on > doing this "the wiki way" as I proposed above. As I said above, we can start with the wiki, and if we realize that it's a problem, move to something else. -- | Lucas Nussbaum | lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Attachment:
signature.asc
Description: Digital signature