Hi there, (mail was stuck in outbox - sorry for delay) sounds great. I am a big fan of the github platform. In that case we should also discuss if we create one repo for each MOJO instead of having one for all as we currently have in SVN (what actually sucks). Then only the core maintainers of each MOJO need permissions. Everything else can be done using pull-requests (PR).
I also have good experience with travis. It is very minimalistic but does a great job. It can also be combined with coveralls to meassure code-coverage. If a PR is provided you automatically get feedback if build succeeds and how coverage is increased or decreased. I would recommend to have different organisations on github for production plugins (and pre-release), sandbox as well as graveyard. This would help to get a better overview. For website the github pages are fine. It is also possible to have sub-pages for each repo in a dedicated branch of the repository. This would work fine with the permissions of each repo and also with PRs. Then you can automatically update the website together with the code-changes if desired and push together. The current URL mojo.codehaus.org should then redirect to the new xxxx.github.io pages. We can also utilize the wiki if that is desired. I am the founder of OASP where we utilize the wiki using AsciiDoc: Publishing releases can work via OSSRH. Issue tracking on github is minimalistic but great. I especially like the way commits get associated with issues and everything gets connected and transparent. Best regards Jörg Am 04.03.2015 um 14:16 schrieb Baptiste Mathus: > OK. Trying to sum up+some points that popped to mind since: > > *Project name* > May not be a concern, but that needs to be cleared out sooner than later. > I think that one of the most pressing subject may indeed not be > technical but about the name of our project: what name should/could we > use for the project. > > Should/could it stay "'Codehaus Mojo" on GitHub even after Codehaus > EOL (meaning we'd certainly use https://github.com/codehaus-mojo org)? > or "Maven Mojo" (which would make googling for it quite difficult > btw)? Or change the project name even more? > > Without that, we won't be able to create the new mailing list, domain > name, and so on. > > *Official Website (Domain name)* > Derives from the previous point I guess. > * > * > *People first : committers* > How should we handle the rights? To minimize the work, I propose we > can create a dedicated mail thread where existing committers willing > to get commit access just have to send a mail giving their GH id. And > even after the migration we'll give rights to the current committers > if they ask but missed the migration. > * > * > *Manifesto* > I thought about that one some minutes ago when re-reading the > Codehaus' manifesto. I think we should have something like that. > * > * > *SCM: Where the sources go* > We seem to have a consensus that moving to GitHub is the most > plausible path for us. I suppose we should call a vote for it? *** > > *Repository migration* > If agreed above that means we'll need to start migrating plugins onto > Git. > I guess we want to ask for feedback & tools from the Apache Maven > project's side since they already did that many a time. > > *Artifact publishing* > I guess we'll need to contact Sonatype to see how we can use the OSS > repo? > > *CI* > CloudBees? Travis-ci? > We need to study the conditions and pricing. > * > * > *Mailing list* > Google groups seems reasonable. > > *Issue tracking* > GitHub Issues > > *Wiki* > If ever needed, GitHub wiki should be fine. > > *Plugins management / Curation* > > As per Robert's mail & in general I think we should analyse the > existing mojos and see those who are active, those who are not, that > may make some of the migration unneeded. I can start that discussion > if needed. > > ---- > Anything else? WDYT? > > -- Baptiste > > > IMHO the Apache Maven team should focus on Maven Core, (java)-build > lifecycle plugins, plugin-development tools, transport (SCM, Wagon) > and project-health tools. > > There are probably a couple of Codehaus-Mojo plugins which might be > interesting to move Apache Maven (assuming legal issues will be > solved). I'm thinking of: > animal-sniffer > build-helper > keytool > mrm > tidy > flatten > (you could also add rmic if you say that all jdk/bin executables > should be wrapped by Apache Maven plugins) > > The codebase under the Apache Maven project use huge, so I don't think > moving everything from Codehaus to Apache will do good, because > priorities for fixes on these plugins will be low. > > What I'd prefer to see is that tools/frameworks would maintain their > own plugins. Think of cobertura, sonar, openjpa, gwt, hibernate, etc. > That would keep these plugins probably more up to date and reduces the > number of projects to maintain. If they think that maintaining maven > plugins is hard, they could always ask some of us to join their team > in order to keep good quality plugins. > > For the remaining plugin: Github looks like the best option right now. > The infra isn't as complete as with Codehaus, so we need be to creative. > > thanks, > Robert > > Op Mon, 02 Mar 2015 13:40:12 +0100 schreef Baptiste Mathus > <bapti...@codehaus.org <mailto:bapti...@codehaus.org>>: > > 2015-03-02 11:40 GMT+01:00 Sergei Ivanov <sergei_iva...@mail.ru > <mailto:sergei_iva...@mail.ru>>: > > I believe the answers to 1. and 2. are yes and yes. Maven > sites can be > published to gh-pages, which is separate to the wikis. As for > 3. I think it > requires investigation. There is a need for a mailing list > like this, and I > am not sure if such case is covered by the GitHub offering. > > > For 1, just checked and you can indeed have a global view of the > issues in > an organization (you must switch context for that). > Example for jenkinsci: https://github.com/pulls?user=jenkinsci > > For 3, we indeed currently receive all the JIRA notifications, and > so on. > IMO this is close to a must if we want to stay as a whole and not > just some > repos patched together wo any form of consistency. I'll check if > we can do > more. > > For 2 I agree this should be sufficient, as our main doc is currently > published as maven-site, this cannot really be an issue. Don't > think we > currently have really used wiki pages. > > -- Baptiste > [1] https://github.com/blog/959-issues-dashboard-for-organizations > > > > -- > Sergei > > > > Monday, 2 March 2015 10:32 +0000 from Lennart Jörelid < > lennart.jore...@gmail.com <mailto:lennart.jore...@gmail.com>>: > Fair point. > I would aim at getting the best of both worlds. If I > absolutely *have* to > move to Apache, I would. But GitHub is currently the better > infrastructure > and process, I feel. > So ... what do we need which is missing from GitHub presently? > * Is the GitHub issue tracker sufficient for our needs? If not > - what is > missing? > * Is the GitHub Wiki documentation feature sufficient for our > needs? Can > it publish Maven site documentation? > * Is the GitHub notification feature sufficient for our needs? > Or do we > need another location for actual mailing lists which are > Discussion-oriented and not related to a particular commit? > > 2015-03-02 11:06 GMT+01:00 Sergei Ivanov < > sergei_iva...@mail.ru <mailto:sergei_iva...@mail.ru> > : > >Mailing lists _are_ important. I was not trying to imply that > mailing > lists should be dropped, merely stating the fact that the > functionality > could be procured elsewhere and plugged into GitHub. If GitHub > does not > provide enough flexibility in that respect, then we need to > talk to GitHub > product team, I am pretty sure they will be listening to the > voice of a > large developer community. > >-- > >Sergei > >> > >>Monday, 2 March 2015 09:54 +0000 from Baptiste Mathus < > bmat...@batmat.net <mailto:bmat...@batmat.net> >: > >> > >>Even if I agree ML shouldn't be an issue. It's not so > unimportant for us > as a developer community. We need a wee bit more than just > pushing and > reviewing code. > >>2015-03-02 9:46 GMT+01:00 Sergei Ivanov < > sergei_iva...@mail.ru <mailto:sergei_iva...@mail.ru> > : > >>>Mailing lists are a completely orthogonal feature to the > development > stack. I am struggling to understand why can they not be > hosted somewhere > else and why the lack of mailing lists is an impediment to > migration to git > and GitHub. > >>>-- > >>>Sergei > >>>> > >>>>Monday, 2 March 2015 08:38 +0000 from Trygve Laugstøl < > tryg...@codehaus.org <mailto:tryg...@codehaus.org> >: > >>>> > >>>>On Sun, Mar 01, 2015 at 12:14:19AM -0800, Dan Tran wrote: > >>>>> Apache process may send some new potential committers > away :) > >>>>> > >>>>> +1 for Github, but stay together under on umbrella of > org.code.mojo > >>>>> groupId. > >>>>+1 > >>>>The concern with moving to Github is their lack of mailing > lists, but > I guess a Google group is the best choice these days. > >>>>> > >>>>> -D > >>>>> > >>>>> btw, i found this https://github.com/codehaus-plexus > >>>>> > >>>>> so we may something similar like that? > >>>>> > >>>>> > >>>>> > >>>>> On Sat, Feb 28, 2015 at 11:26 PM, Tony Chemit < > che...@codelutin.com <mailto:che...@codelutin.com> > > wrote: > >>>>> > >>>>> > On Fri, 27 Feb 2015 12:51:18 +0100 > >>>>> > Lennart Jörelid < lennart.jore...@gmail.com > <mailto:lennart.jore...@gmail.com> > wrote: > >>>>> > > >>>>> > > I second the opinions for moving to GitHub (or > Bitbucket) > instead of > >>>>> > > remaining in SVN. > >>>>> > > If doing so, I suggest we reuse as much as possible > of the GitHub > >>>>> > > infrastructure - Wiki, Issue Tracker, Mailing lists etc. > >>>>> > > If we are already bound for some major migrations, > let's make > the best of > >>>>> > > them - and a Distributed version control system is a > productivity boost. > >>>>> > > > >>>>> > > Also - is there really a point to maintain a > particular GroupID > (i.e. > >>>>> > > org.codehaus). > >>>>> > > I belive we could/should move Mojo's development > efforts into > the Apache > >>>>> > > umbrella (why have 2 sources of normative plugins - > apache and > codehaus) > >>>>> > to > >>>>> > > simplify for users. > >>>>> > > >>>>> > I really like this idea to *merge* mojo projets with > maven plugins > one or > >>>>> > something at apache house. > >>>>> > > >>>>> > I guess there is some legal issue about it ? or not ? > >>>>> > > >>>>> > > >>>>> > > >>>>> > -- > >>>>> > Tony Chemit > >>>>> > -------------------- > >>>>> > tél: +33 (0) 2 40 50 29 28 > <tel:%2B33%20%280%29%202%2040%2050%2029%2028> > >>>>> > http://www.codelutin.com > >>>>> > email: che...@codelutin.com <mailto:che...@codelutin.com> > >>>>> > twitter: https://twitter.com/tchemit > >>>>> > > >>>>> > > --------------------------------------------------------------------- > >>>>> > To unsubscribe from this list, please visit: > >>>>> > > >>>>> > http://xircles.codehaus.org/manage_email > >>>>> > > >>>>> > > >>>>> > > > >>>>--------------------------------------------------------------------- > >>>>To unsubscribe from this list, please visit: > >>>> http://xircles.codehaus.org/manage_email > >>-- > >>Baptiste <Batmat> MATHUS - http://batmat.net > >>Sauvez un arbre, > >>Mangez un castor ! > -- > -- > +==============================+ > | Bästa hälsningar, > | [sw. "Best regards"] > | > | Lennart Jörelid > | EAI Architect & Integrator > | > | jGuru Europe AB > | Mölnlycke - Kista > | > | Email: l...@jguru.se <mailto:l...@jguru.se> > | URL: www.jguru.se <http://www.jguru.se> > | Phone > | (skype): jgurueurope > | (intl): +46 708 507 603 <tel:%2B46%20708%20507%20603> > | (domestic): 0708 - 507 603 > +==============================+nbsp;! > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > >
smime.p7s
Description: S/MIME Cryptographic Signature
