+1 Particularly as these are not day-to-day but every-now-and-then tasks ..
Regards Felix > Am 05.06.2017 um 17:32 schrieb Julian Hyde <jh...@apache.org>: > > +1 > > It moves us towards a self-service (dare I say “github-like”) experience for > podlings, and that is always good. > > Furthermore, if there are choices to be made (e.g. svnpubsub vs. CMS) I think > the tooling should strongly encourage them to take the “standard” option. > Maybe it doesn’t even present the other option(s) at all. When my project was > going through incubation I was forever worried about stepping on some > infrastructure landmine and as a result did nothing for several months. > > Julian > > >> On Jun 4, 2017, at 7:33 PM, John D. Ament <johndam...@apache.org> wrote: >> >> All, >> >> I want to bring up this discussion to see others opinions. I would like to >> move forward on migrating podling status maintenance into Whimsy. Some of >> the key things I want to improve upon is the overall experience around >> managing the podling. Sam's done a great job with rosters, but we can >> start to track other things in whimsy, which mirrors what's in the status >> file. This can include IP Clearance/SGAs, Podling Name Searches, the >> various dates we track. >> >> Ultimately, I want to simplify how podlings are managed and make it a bit >> easier on an end user. Rather than needing to svn checkout to get files, >> they simply go to a webpage, and assuming they're on that podling's roster >> they would have access to update the status. We could even automate >> certain events so that when the board passes a resolution to graduate the >> podling, the status file is updated along side any other record the podling >> may have. >> >> This does mean that the status file format is likely to change. It also >> means we're likely to move away from the java based build tool that has to >> parse the XML templates into web pages and instead rely on a more >> structured format for the status. >> >> It doesn't mean you have to change. If you like using SVN to edit this >> stuff that's fine, you would still be able to. Just what you're editing is >> likely to be different. >> >> Thoughts? Opinions? >> >> John > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org