[forgot the reply-all, sorry] On Jan 21, 2008 12:54 PM, Mathias Hasselmann <[EMAIL PROTECTED]> wrote: > Am Montag, den 21.01.2008, 12:16 +0100 schrieb Olav Vitters: > > On Jan 18, 2008 9:49 AM, Olav Vitters <[EMAIL PROTECTED]> wrote: > > > Summary: I'd like replace the MAINTAINERS requirement by doap files. > > > > > > > I have a partial script that I want to expand to include as much info > > > as I can possibly can add automatically (everything until the 'and others' > > > above). > > > > Just highlighting the parts that have been missed. I'd appreciate, but > > it is *not at all required* to do any work after the script changes > > the format from MAINTAINERS to doap. The field that I *require* is the > > maintainer part (again: will be converted). All the other fields are > > extra's. Nice to have, really appreciated if provided, but not > > required. > > So I understand even less, why you want us to use a file format which as > several technical problems: > > - hard to read and write
Is this technical? It isn't the perfect format. However, it is doable. Further, you already suggested the .ini like format, which still is not an ideal solution (as maintainers had problems with MAINTAINERS). I understand it is more difficult than MAINTAINERS. However, coupled with there will be a conversion and that it mostly is a one-off thing, I don't think it matters. > - redundant with AUTHORS file AUTHORS is not always there, not readable by machines, not always in a standard location and the layout often differs. Further, I don't care if someone puts AUTHORS in doap. If someone does, people could generate AUTHORS from DOAP. Initially I don't care to have AUTHORS in DOAP, maintainers are free to either include it or not (quoted above: "All the other fields [aside from maintainers] are extra's"). > - redundant with Changelog, NEWS and FTP I don't see any relation to that. > - no support for git or bzr It is for GNOME SVN. Why should I care ATM for git/bzr? I'd like some *existing* format that includes that. However, couldn't find anything and I hate making a new format and then having to recreate whatever exists for some existing format. > You want additional information for svn-commits-list, web-sites? I have more ideas, which I'll keep to myself to limit the amount of stop energy per week. > You want to provide the service of hosting DOAP files? So keep > MAINTAINERS (and AUTHORS, and whatever DOAP related information we > already have), add some PROJECT-INFO file that lists the missing pieces > of information, and generate the DOAP file. No. MAINTAINERS can go (again, no enforcement). AUTHORS: maintainers will be free to add such info to DOAP, don't care. It would be great if that is in DOAP and e.g. autogen.sh generates such a file. I don't care if it happens or not. Not sure what you mean with FTP. I could remove ftp.gnome.org, but DOAP will not provide tarballs and I think not everyone wants to create tarballs from SVN. > > The script will fill in a lot of fields, as explained in my initial > > email. Any info that could be fetched from somewhere will be included > > / updated automatically. In practice I don't think you'll notice on > > the short term. > > What about new modules? First of all they have to copy boilerplate code, > to get a valid DOAP file - very bad engineering. Second they have to lie > at many fields, as new modules usually do not have a Website or Bugzilla > and such yet... You seem to think I dismissed your suggestion while I haven't commented on it yet. You suggestion would output DOAP anyway. I'm strictly discussing the possibilities of 1) having such info in one place 2) amount of work required from maintainers while not discussing if the inital input is doap or something else. DOAP has an special method for people wanting to fill in bad information. It is done by not including the field if you either don't know it, or whenever you want to fill in bad information. I really hope your .ini-like suggestion follows the same logic. > > I know changing this part of the infrastructure (maintainers vs doap) > > for the second time is not ideal. However, some things are just needed > > to have a better infrastructure. E.g. Mango would not work without > > knowing the maintainers in some machine parseable way. > > Mango rocks, and MAINTAINERS indeed was a good idea. It doesn't work in practice, as already explained (details in other emails). I could add more strict pre-commit checks, but I rather move to a better format. Regards, Olav _______________________________________________ Gnome-infrastructure mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-infrastructure
