On Wed, 2015-11-04 at 22:09 +0100, Egmont Koblinger wrote: > getting to know the development process, policies (e.g. which changes > require approval, when to git branch, etc.), and
Well, basically it's all about having a ticket & a topic branch per feature / non-documentation bugfix, where ticket number and summary are in the commit message along with a short description and a sign-off, and doing a --no-ff merge when it's finished (i.e. rebase first to keep the history nice and clean), see git log. Changes to the documentation, maintainer scripts, translations, etc. can go directly into master. There is more legalese on the trac at various stages of bitrot, but that's basically all that matters to me, I think. Does this sound reasonable to you? > requesting to get faster responses to my patches that require review – > or to be able to submit them if I don't get response in a certain > amount of time. Here comes the tricky part; the first rule was that the branch gets merged as soon as it gets 3 votes from the maintainers other than the main author, then it was quickly changed to 2 votes, and then eventually degraded into 1 vote, and then... then you know what happened. How about doing it the other way around from now on? You put the branch on review, and if there is no vote coming, and no one vehemently objects on technically substantiated grounds, it can go into master after 4 weeks, or I can rubber-stamp it if you want to keep the formalities :-) Does this sound reasonable? > keep doing what I did so far and do even more, but without > obligations. The obligations anyone here has are at best the "moral" ones. There is no signing of contracts involved in getting commit access. Only I'd expect you not wiping the repository after a tequila party, feeling responsible for fixing stuff you happened to break, being careful with the private keys if you need/want access to more infra, etc. and in general keep the pills handy. I don't think this would be a problem, would it? -- Sincerely yours, Yury V. Zaytsev _______________________________________________ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel