Sebastian Schaffert wrote on Tue, Mar 19, 2013 at 22:18:03 +0100: > Hi Daniel, > > Thanks for setting this up so quickly! > > 2013/3/19 Daniel Shahaf <[email protected]> > > > Sebastian Schaffert wrote on Tue, Mar 19, 2013 at 21:43:29 +0100: > > > Hi Daniel, > > > > > > thanks for the friendly and helpful answer. > > > > > > 2013/3/19 Daniel Shahaf <[email protected]> > > > > > > > You were expected to file an infra ticket prior to doing this (so that > > > > commit mails get set up correctly) > > > > > > > > Do docs say that? > > > > > > > > > > No, not that I am aware of it. I was following the following guidelines: > > > - > > > > > http://incubator.apache.org/guides/releasemanagement.html#release-distribution > > > > Right. And > > > > http://incubator.apache.org/guides/releasemanagement.html#understanding-upload > > says "podling dist dir" and links to a definition of that. One or both of > > those places should probably say that you may not create it yourself and > > need instead to file a jira. > > > > This would be very helpful, yes. :) > > > > > > That's for two reasons: mailer config and svnwcsub setup. I've just > > made a tweak to the former - can you mkdir /release/incubator/marmotta > > and confirm that your commits@ list receives a notification of that? > > > > I tried it and the mail was delivered correctly. Thanks! >
Cool. I just made a few more config changes that, among other things, mean future podlings don't need infra interventions for mailer config during podling dist dir creation. It shouldn't cause any visible difference, but if you notice any oddities (eg, missing commit mails), let us know. Specifically, _for @podling.i.a.o podlings only_, the project can now create the dist dir for itself. This doesn't apply to TLPs nor to "old-style" podlings. > > > > > I'm inclined to leave the latter as-is, though: one svnwcsub line per > > podling. Which means the need for a jira ticket remains. > > > > Can you patch the incubator docs, then? > > > > Unfortunately this is out of my scope, I am just the release manager for > Marmotta and can only make suggestions to the incubator PMC. I will suggest > a patch to the mailinglist tomorrow. > Dunno how they work; maybe you should just commit to CMS and ask the list to review it on staging before you publish. Or maybe the documentation belongs on /dev/infra-contact (or /dev/release)? Things like the above distinction (which projects should/shouldn't mkdir their own dist dir) should be documented on the infra pages, IMO. > > > > > - http://www.apache.org/dev/release-publishing.html > > > - http://www.apache.org/dev/publishing-maven-artifacts.html > > > > > > The first two documents both describe (among many other things) the SVN > > > distribution repository. None of these places mention that I would be > > > expected to file an INFRA ticket. Sorry if I overlooked yet-another > > > document when preparing the release. Could you please point me to it so > > we > > > can include it in our release process? > > > > > > > For starters http://www.apache.org/dev/release. > > > > There's no clear place explaining "you need to talk to us" (that's more > > http://www.apache.org/dev/infra-contact#requesting-podling material), > > but I suppose we could add a paragraph about that to > > http://www.apache.org/dev/release#heads-up. Or just change the authz > > file so podlings _can't_ create their own dist dirs. > > > > Maybe the best option would be to somewhere have a checklist which services > are actually to be requested for a podling. Would have made it easier for > us. I think the first link (...#requesting-podling) is the best place for > this. > Have you got concrete improvement suggestions? (If you do, feel free to ask this list to review them pre-commit or pre-publish.) From my POV, the most important thing to clarify is that the mailing lists must have been CREATED (not only requested) before things that email them are created[1]. Thanks Daniel [1] that includes "before mkdir /repos/asf/incubator/podling", as well as "before mkdir /repos/dist/*/incubator/podling" (that's a mistake people are unlikely to make, IMO) and "before account requests are made" (those are CC'd to IPMC, but I imagine that creating the private@ list first, then populating it with initial PPMCers, _then_ making the account requests would provide better oversight on their contents)
