On Saturday, May 19, 2012 4:16:13 PM UTC-5, Ernie Rael wrote: > > > >> 1. I want to maintain all changes to my file. Please don't touch it beyond > >> what I send you. I commit to be responsive enough for this to work. > >> 2. I want to do all "big" changes and feature additions, but "small" > >> changes > >> and bugfixes can be done by the team. I will maintain my files in a way > >> that changes will not be lost from the runtime repository. > >> 3. I want to remain the official maintainer of the file, but the file > >> belongs > >> to the Vim community. Do what you will with it, I'll submit changes > >> like > >> any other contributor. > >> 4. I do not wish to be the maintainer anymore. Please take it on as a group > >> effort or find someone else. > (usually a lurker, but for some reason process issues...) > > The above "file maintenance levels", which imply maintainer > role/responsibility for a given file, seem about right and should > satisfy Dr. Chips' concerns. (procedural question: should the maintainer > level appear in the header of the file in question? And in general what > is in a file's header? Should header have a particular format so it can > be grep'd for stats/summaries) >
Yes, I think this would be a good thing to put in the file header. And sections of a file with special considerations, like the auto-generated section of the Vim syntax file, could have a prominent comment nearby alerting any potential contributors. > In some ways, 3 and 4 are almost the same; they do feel different, but I > don't really see a functional difference. If all discussions of changes > (except possibly for level 1 maintainer) occurs in a public mailing > list, what duties/responsibilities does a level 3 role have compared to > level 4? Maybe there are only two roles, along with "no maintainer". > level 3 might be useful as a "file guru" for questions, especially if > the guru no longer subscribes to vim dev. I think level 3 has two major differences from level 4: 1. the official maintainer would be the "default" person to make changes from suggestions on the list, bugfixes, etc. 2. the official maintainer would be a "file guru" as you say, at least until the team maintainers gain the needed knowledge, which might take years if it ever happens. Many runtime files change quite infrequently. > > IMO, the following should be part of the procedural description of how > this new maintenance model works and not a file maintenance level. > > 5. We need to know who is an active member of the community. If you are > > still > > interested in maintaining your files make sure that the email address > > that > > is shiped with your files is up to date and functional. > > If we do not hear from you within the next 3 months or the email we > > send > > to you bounces we consider you to be MIA. > > In that case we *regard your files to be without current maintainer* > > and > > put them under the provsion of the vim community. > > > Agreed. I think level (1) is the only level appropriate for including only a personal address in the file. Level (2) could probably list the vim_dev list as primary contact, and the maintainer as a secondary if at all (in case the maintainer wants to be CC'd on emails to the list). Level (3) or (4) should probably just list vim_dev. I think when we get this underway we'll want to contact all the maintainers (also to give them access to the "incoming" repository if they want it), and any who have not responded/could not be contacted in a month or so would default to "unmaintained" unless we hear otherwise. Without a deadline I'm pretty sure we'd have at least a few files in a state of limbo for a long time and I'd not like to see that preventing the transition. > By other mail it looks like the big procedural issue of repository > hierarchy/operation is getting close to agreement. mercurial does have > an ACL extension, http://mercurial.selenic.com/wiki/AclExtension; but > that might be overkill and/or too much maintenance. I have no experience > with it, but I thought I'd bring it up. See my other email; if we use a clone of the main Vim repository, or a subrepository of all the runtime files, this might be a good way for Bram to restrict access to places we ought not be modifying. We might also use this to restrict access on those files under maintenance level (1). Again, I'm not sure about support for this extension at Google Code, BitBucket, or SourceForge. I'm pretty sure we don't want to administer our own server. I'm more doubtful of this one than subrepository support, though. At least this thread says BitBucket didn't support it back in October 2011: http://stackoverflow.com/questions/7920634/is-it-possible-to-use-mercurial-acl-extension-in-a-bitbucket-repository I couldn't find anything on Google Code or SourceForge. -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
