> Simultaneous Release products (see Bug 500512). > a side note, we need to have a better answer for reporting bugs against > considering the number of bugs that are incorrectly opened against JDT). > Moving issues from one team's bucket to another team's bucket is not (In reply to Wayne Beaton from comment #3) It's not clear to me at this point if the inability to easily move issue or mark duplicates is a fundamental flaw in Tuleap or simply something that just hasn't been implemented yet. Tuleap also does not currently provide an easy means of marking duplicates. On a side note, we need to have a better answer for reporting bugs against Simultaneous Release products (see Bug 500512). Moving issues must be easy (especially considering the number of bugs that are incorrectly opened against JDT). Moving issues from one team's bucket to another team's bucket is not supported. Customisation can be templated, which may make it possible to share some set of common customisation. My understanding, however, is that the user experience for this sort of administrative task is not as refined as the user-facing interface. It is possible to add custom fields into a project team's bucket to capture information that may be specific to another project. Tuleap provides fine-grained permissions which would make it relatively easy to, for example, grant a project lead the ability to grant access to non-committer triagers (I believe that our various policies permit this sort of thing).
There is a notion of a project landing page that likely overlaps (at least a little) with the PMI it may be worth investigating integration options (I'm not particularly keen on project teams being required to manage multiple landing pages on different services). we may be able to also deprecate the Eclipsepedia wiki). These features may permit us to migrate other services into Tuleap (e.g. It is relatively easy for a project team to create additional Git repositories from directly within the Tuleap interface. Tuleap provides all sorts of other services, including a wiki, document management, and Git hosting. I've learned a little bit more about Tuleap. GitHub Issues will continue to be an option for projects that opt to host on GitHub.
#Bugzilla hosting free#
Feel free to argue.Īs part of this effort, we should also evaluate other options. I'm not 100% sure, but this feels like it's concerned with simplifying Committer workflow, so I've added Bug 435599 as a blocker. Let's have general discussion on this record, and add blockers for specific things that need to be addressed. Please note that I am not at this point suggesting that we should do this, but rather that we should start the process of deciding if we want to and whether or not it is possible. * PMI (has some integration with Bugzilla).
#Bugzilla hosting generator#
* IP Log generator (pulls some data from Bugzilla) and * Old project plan (uses Bugzilla queries to populate bug lists) * AERI (has a means of automatically creating Bugzilla records) * Other documentation/wiki references Bugzilla an awful lot * How complete is the migration of records from Bugzilla to Tuleap (what information will we lose)? * Do we implement this on all forges (Eclipse, LocationTech, PolarSys)? * Can we scale this to handle all of our projects? * Tuleap supports the new OpenId infrastructure that the EF provides.
* Existing Bugzilla records can be migrated to Tuleap and * AFAIK, Tuleap provides "basic issue tracking" features that are conceptually similar to what Bugzilla provides (i.e. * Bugzilla isn't getting a lot of love these days Ideally, if we do decide to adopt Tuleap we would deprecate Bugzilla and begin a migration process similar to what we did when we moved from CVS to Git. Let's investigate whether or not it makes sense to encourage a wholesale migration from Bugzilla to Tuleap. Some project teams have started to experiment with Tuleap.
0 kommentar(er)
