Hi Daniel, first of all, thanks for all the work. It will really help future podlings.
2013/3/19 Daniel Shahaf <[email protected]> > > > > > > > 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. > Great. Does this mean we can leave the documentation as it is (i.e. no need to create a ticket)? Are all future podlings going to be created in the "new style"? > > > > > > > > > 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. > Never hurts to have it in two places, especially the release guide for podlings (because this is obviously the first document that is checked). The document says that suggestions for improvement should be sent to the incubator general mailing list, so I'll do that if after your changes the ticket is still necessary (see above). > > > > > > > > - 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]. > In this concrete case, the mailinglist has been in place already for two months. The only thing that was apparently missing was the forward of the commit message to the list. So my suggestion is to have a table that lists: - what services from INFRA are strictly required for every project (and how the tickets should look like) - what services can optionally be provided by INFRA for a project (e.g. Nexus or Jenkins) Unfortunately I don't have the complete overview, so I'd prefer someone with more experience in the ASF to do a concrete suggestion. Greetings, Sebastian
