Because GEF is contained in pretty much all the stack traces of its adopters (GMF, Sirius, Papyrus and others) I find myself triaging several issues that are actually not related to problems in GEF. That’s fine, I don’t want to lament that GEF has a lot of adopters and of course I want to support them all. However, I recently ran into cases were issues were indeed already triaged (i.e. a bugzilla was created for a specific project), but the list of projects was not adjusted. In order to reduce overhead, it would IMHO be a good policy to remove other projects from an AERI issue in case triaging leads to a bugzilla for a specific project (the projects list can easily be edited during triaging, and non-related projects can simply be removed from it).
Cheers Alexander -- Dr. Alexander Nyßen Dipl.-Inform. Principal Engineer Telefon: +49 (0) 231 / 98 60-202 Telefax: +49 (0) 231 / 98 60-211 Mobil: +49 (0) 151 / 17396743 http://www.itemis.de [email protected] itemis AG Am Brambusch 15-24 44536 Lünen Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
