Re: Policy for Debian Qt/KDE Maintainers Group
On Sun, Oct 19, 2003 at 04:20:42PM +0200, Martin Loschwitz wrote: I prepared a policy for the Debian Qt/KDE Maintainers Group, the document can be found at http://people.debian.org/~madkiss/debian-kde-policy.html Hi, Just a few clarififications: 1. About alioth: Will we have the entire kde packages in alioth svn or just the debian/ dirs? I know we can't at the moment use pristine upstream tarballs, but having the entire source tree in our version managment feels like a HUGE waste of space, as we are supposed only to edit files under debian/ dirs.. 2. About commits to module, I think we should rewrite it as: - (5) Commits to a module may only be done if + (5) Commits to the TRUNK of a module may only be done if Creating a branch where to commit fixes and then letting primary maintainer to merge them to TRUNK if he finds them appropriate seems more intuitive than asking for permission for every commit. I'm refering TRUNK being here whatever we choose in svn to be the branch which next unstable upload will emarge from. Also, I think we should not be that strict for all commits. Strictly nonfunctional commits, like typofixes, better descriptions and documentation (Maybe even adding manpages) should be fix at will. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver | pgpopD8MwVu9M.pgp Description: PGP signature
Re: Policy for Debian Qt/KDE Maintainers Group
On Wed, Oct 29, 2003 at 01:30:42PM +0200, Riku Voipio wrote: On Sun, Oct 19, 2003 at 04:20:42PM +0200, Martin Loschwitz wrote: I prepared a policy for the Debian Qt/KDE Maintainers Group, the document can be found at http://people.debian.org/~madkiss/debian-kde-policy.html Hi, Just a few clarififications: 1. About alioth: Will we have the entire kde packages in alioth svn or just the debian/ dirs? I know we can't at the moment use pristine upstream tarballs, but having the entire source tree in our version managment feels like a HUGE waste of space, as we are supposed only to edit files under debian/ dirs.. agreed. 2. About commits to module, I think we should rewrite it as: - (5) Commits to a module may only be done if + (5) Commits to the TRUNK of a module may only be done if Creating a branch where to commit fixes and then letting primary maintainer to merge them to TRUNK if he finds them appropriate seems more intuitive than asking for permission for every commit. I'm refering TRUNK being here whatever we choose in svn to be the branch which next unstable upload will emarge from. Also, I think we should not be that strict for all commits. Strictly nonfunctional commits, like typofixes, better descriptions and documentation (Maybe even adding manpages) should be fix at will. agreed. I will be getting the repo in a usable state within the next couple of days. Chris signature.asc Description: Digital signature
Re: Policy for Debian Qt/KDE Maintainers Group
I was a bit scared reading about Chris Cheney orphaning his KDE packages in the unreleased DWN and wnpp mailout... I'm glad to see that the group discussed earlier was/is actually being created. Now, some comments on http://people.debian.org/~madkiss/debian-kde-policy.html Reading paragraph 1(3), I worry about only allowing the group to remove people doing malicious things... Perhaps some examples of malicious behavior would be useful. E.g. knowingly going against the policy document? Knowingly doing things that the Debian technical committee vote is unacceptable for Debian? - Paragraph 1(2) should probably be clarified. If there are no objections... If there are no formal objections... what's the time period during which objections can be made? Perhaps people should be revocable added during the objection period. I.e. added ad hoc, but if there's an objection in time, then they can be removed without having use paragraph 1(3). - Paragraph 2(8) - (8) A primary port maintainer may turn down the rights given to him in 2.5, 2.6 and 2.7 and allow one member or all members of the Debian Qt/KDE... + (8) A primary port maintainer may turn down the rights given to him in 2.5, 2.6 and 2.7 and allow some or all of the members of the Debian Qt/KDE... It is probably not desirable to limit co-maintainership to only one or all. - Paragraph 2(9) talks about a consensus with the mailing list. Perhaps this should be a consensus with the group? Also, a semantic issues, it should be Changes to this policy, not file or else you're contradicting the license of the file. - Drew Daniels P.S. please CC replies to me.
Policy for Debian Qt/KDE Maintainers Group
Hi folks, I prepared a policy for the Debian Qt/KDE Maintainers Group, the document can be found at http://people.debian.org/~madkiss/debian-kde-policy.html Can you (esp. the people mentioned as base members) read it and tell us whether they want to lodge objections and if so what needs to be changed in their opinion? And can those who do not have any objections please let us know that too? Thanks in advance, -- .''`. Martin Loschwitz Debian GNU/Linux developer : :' : [EMAIL PROTECTED][EMAIL PROTECTED] `. `'` http://www.madkiss.org/people.debian.org/~madkiss/ `- Use Debian GNU/Linux 3.0! See http://www.debian.org/ signature.asc Description: Digital signature
Re: Policy for Debian Qt/KDE Maintainers Group
Can you (esp. the people mentioned as base members) read it and tell us whether they want to lodge objections and if so what needs to be changed in their opinion? And can those who do not have any objections please let us know that too? Further to my previous email: My second question is how the proposed development model (upload if you're the primary maintainer or have their blessing) differs from the current model (upload if you're the debian maintainer or NMU if you have their blessing)? I guess I'm specifically wondering what advantages the new system would have over the current system (which is more or less communal CVS commits, maintainer uploads). I think the biggest inconvenience I forsee is with the BTS - I'd have to start keeping track of multiple maintainer email addresses, and it will be more difficult to track the bugs in the packages that I'm looking after amongst the significant noise of kdelibs, kdebase, qt, etc. Ben. :)
