Hi, We always value good opinion. I'm not very enthusiastic about migrating from JIRA to GH issues. I don't really see the gains compared to the efforts. Though, it seems we can have the same features on both sides. So why not? 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 2014-07-10 16:29 GMT+02:00 Dmitriy Kopylenko <[email protected]>: > 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 > > -- 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
