I am personally totally onboard with the move to GH issues, but my voice doesn’t count ;-)
Cheers, D. On Jul 10, 2014, at 10:26 AM, Misagh Moayyed <[email protected]> wrote: > ًWhile we are making progress, I thought I'd revisit this topic and see where > we stand, particularly on moving away from Jira and over to Github issues. I > have got some time today and tomorrow to make the effort to move open JIRAs > over and configure issue tracking. Is the majority onboard with the move, or > are there other considerations we should take? > > From: "Misagh Moayyed" <[email protected]> > To: [email protected] > Sent: Saturday, June 7, 2014 8:57:37 AM > Subject: RE: [cas-dev] CAS 4.1.0 > > Thanks for clarification on the roadmap. > > Notes follow: > > @JPATicketRegistry: > I am not sure if it’s the most widely used one. I’d think the default > in-memory registry is the one that is used most often and works quite well if > one is not after an HA deployment and is the least complex option. After all, > it requires you to do absolutely nothing. The JPA one is attractive because > it provides durable space specially useful for remember-me, but in reality > and my experience, it is first and foremost evaluated by folks to implement > HA with CAS. Nonetheless, I think we can find and agree on better and more > robust alternatives. I don’t have any particular options at hand at the > moment, perhaps a NoSql solution would work better and be easier to set up > and clean…perhaps an in-memory registry that is backed by MongoDb, or > something else…At the very least, I think we should strongly encourage folks > that the JPATicketRegistry should not be considered for HA deployments. > > @Github Issues: > So, we have to do a little bit of work to create some appropriate tags that > correspond to our existing JIRA issue types, but that’s quite simple to do, > takes very little time and the process is in fact quite customizable. Every > issue can be assigned to a milestone, and may be tagged with many other > decorations that JIRA provides. Issues can be assigned to developers, can > have “Affects Version” and “Fixed in Version” and many other tags that we > feel may be more relevant. > > References: > https://github.com/blog/831-issues-2-0-the-next-generation > https://help.github.com/articles/customizing-issue-labels > > Again, it really feels like we are just using JIRA as a task list but there > is just a bit of disconnect. Not everyone, I am not sure, is subscribed to > all JIRA issues that are reported; a separate system requires a separate > account which requires extra cleanup and maintenance. Github issues can take > care of all of this. > > Now, there is a bit of downside, where we lose the ability to create private > issues. I am not sure how that may be implemented, if it can at all. > > @Downloads Link > I think the Jasig website needs to point to a place where folks can download > CAS. But that’s a one time modification. We can simply point the link to the > place where binary downloads are available on Github, and people can choose > which version to download and adopt. > > Reference: https://github.com/blog/1547-release-your-software > > @Release Process > We definitely do need to take some action there. I have considered gradle for > the build and while it works fine, I have not seen any significant > improvements yet. Now, I think the heart of the issue lies with the > maven-release plugin and various problems we have had with git and platform > types. We may want to look into BinTray and see how that helps. It should > sync with maven central, which is what we really care about and does come > with its own set up of plugins that may work better. I am not sure yet, but > it seems like a viable option. > > Reference: https://bintray.com/ > > > From: Jérôme LELEU [mailto:[email protected]] > Sent: Thursday, June 05, 2014 3:06 AM > To: [email protected] > Subject: Re: [cas-dev] CAS 4.1.0 > > Hi, > > 2014-06-05 3:11 GMT+02:00 Misagh Moayyed <[email protected]>: > …oh, one more thing to consider: > > - Rather than providing binary downloadable artifacts per release on > the jasig website, it seems like the release engineer for a given CAS release > has all the right permissions and tools to take advantage of the Github’s > releases feature, where the binary artifact, cas-webapp as well as release > notes can directly be hosted and uploaded there. The jasig website could then > perhaps just include a link to the latest release, or to the download area. > If you have to create a link in the Jasig web site, I'm not sure to see the > benefit: using the text editor for the web site is a bit painful, either for > just a link or a more complete description... > > > My objective really is to try and simplify the release process, by keeping > code, docs, and artifacts all close in the same spot and seems like Github > serves this need quite well for the time being. I imagine this would also be > much easier for CAS users as well, where they get the code, docs, and the > downloadable artifact and release notes (Just the piece that is uploaded to > the jasig wiki that is) all from the same place. > > I'm in line with your objective, but we didn't talk about the worse part from > my point of view: the Maven release prepare and perform tasks... > > Best regards, > > -- > Jérôme LELEU > Founder of CAS in the cloud: www.casinthecloud.com | Twitter: @leleuj > Chairman of CAS: www.jasig.org/cas | Creator of pac4j: www.pac4j.org > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
