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". >> 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
signature.asc
Description: OpenPGP digital signature
