Hi Chris, On Fri, Jun 17, 2016 at 12:51 PM, Christopher Schultz < ch...@christopherschultz.net> wrote:
> Martin, > > On 6/8/16 3:25 AM, Martin Grigorov wrote: > > On Tue, Jun 7, 2016 at 11:33 AM, Mark Thomas <ma...@apache.org> wrote: > > > >> On 07/06/2016 10:17, Martin Grigorov wrote: > >>> Hi devs, > >>> > >>> Recently a colleague of mine asked me what it takes to become an Apache > >>> committer. > >>> I've explained him that he has to choose a project that is interesting > to > >>> him and start participating in the mailing lists (helping others at > >> users@, > >>> giving opinion and testing releases at dev@), providing patches for > open > >>> issues, etc. > >>> Few days later he came back with the following questions: > >>> > >>> 1) Why Tomcat still uses SVN? > >>> I've told him that this is the SCM tool most of the committers have > >>> experience with and there were some discussions to move to Git several > >>> months back. > >>> I've recommended him to use GitHub's Pull Requests for the time being - > >> PRs > >>> are monitored and merged if approved. Even if Tomcat was using Git, > >> Apache > >>> Infra doesn't provide tool with Pull Request support (GitLab, Gerrit, > or > >>> similar) anyway so there is no big difference from a contributor point > of > >>> view. > >> > >> If I recall correctly, the consensus last time around was that there was > >> merit in exploring the options for using git further with a view to > >> migrating if the majority were convinced there was a benefit to the > move. > >> > >> There is an outstanding task (I need to chase it up) for the infra team > >> to look at if we could move to a single git repo for multiple branches > >> or would need multiple repos. > >> > > > > One repo should be possible. > > Even if there are some problems with the initial conversion from SVN to > Git > > the person dealing with it could create N Git repos and then with the > help > > of "git remote add" combine them into one with N branches and finally > push > > those branches into a single repository. > > > > > >> > >>> 2) Why Tomcat uses Bugzilla? > >>> It is archaic and its UI is unfriendly - he said. > >>> To be honest I didn't have a good answer here. I also don't like > >> Bugzilla. > >>> Everybody knows how to use JIRA! It is hard to explain that Apache JIRA > >>> runs on Tomcat, but Tomcat project itself uses Perl software for issue > >>> tracking (no matter how good Bugzilla is). > >> > >> My personal view is Jira is overly complex and horribly slow. Bugzilla > >> > > > > I think JIRA is slower because the majority of the projects are there. > > But I guess it would be an overkill for Infra to maintain several > instances > > of JIRA (e.g. sharded by project name). > > I think it's slower because it's a sledgehammer where a screwdriver will > do the job. I've never liked JIRA, but as was previously said "tools are > tools". > At my $dailyJob JIRA is not slow at all. It is Apache JIRA installation problem, not every JIRA installation. If you are subscribed to infra@ you will see that people complain relatively often that it is either down or slow. Last such mail is from yesterday! IMO Apache JIRA should be split into several instances. But here is not the place to discuss this topic! What I was trying to explain is that Tomcat looks like an ageing product from a tooling point of view: Bugzilla, SVN, ANT, Gump. It is hard to make Tomcat development attractive to work with tools from the 90s (figuratively said). I am not saying that by changing the tooling suddenly a lot of developers will want to contribute! I just share the opinion that many developers consider these things when trying to find an OSS to contribute to. > >> just works. We don't need any of the extra features Jira offers. Do we > >> want any of them? None come to mind. Others may have a different view. > >> > > > > I personally like the JIRA plugins that integrate with the SCM tools. > > Committing with "PROJECT_NAME-1234" in the commit message automatically > > adds a comment to the respective ticket with a link to Git/SVN repo. It > is > > very easy to explore the history of a ticket. > > All of this can be done with svn + bugzilla, too. I guess just nobody > bothered to do it @ASF until JIRA came along. > > > Also it has a proper "Fix version" field. With it it is much easier to > > create a changelog. No need to maintain one manually. > > Bugzilla has a "Target Milestone", but that is disabled in Bugzilla, > probably because the list of milestones would get insanely long. Maybe > another reason that JIRA is so slow: all that metadata is actually in > there instead of having been deemed "too much" at some point in the past. > > >>> I know that SVN, Git, JIRA, Bugzilla are just tools. We can do our work > >>> with any of them. > >>> Maybe there are more (and more important!) reasons why my colleague > >> didn't > >>> start contributing to Tomcat yet but I also agree with him that by > moving > >>> to more modern tools Tomcat will become easier and friendlier for > >> newcomers. > >> > >> The Tomcat community tends to change development technology when it can > >> see some direct benefit from the change. It doesn't change just to use > >> the latest shiny new toy. > >> > > > > I totally agree with "see some benefit"! > > I don't agree with "new" :-) Both Git and JIRA are on the market for > quite > > some time. > > The age of the toy is not really relevant. It's the relative merit to > the current toy. So far, I don't see any merit in switching to JIRA. My > recent forays into git have shown me that it can help with collaboration > from non-committers, which I think is always a good thing. > > -chris > >
