On, Wed Oct 29, 2014, Eitan Adler wrote: > On 28 October 2014 15:14, Baptiste Daroussin <b...@freebsd.org> wrote: > > On Tue, Oct 28, 2014 at 09:35:26PM +0100, Marcus von Appen wrote: > >> > >> Quoting John Baldwin <j...@freebsd.org>: > >> > >> > On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote: > >> >> Hello, > >> >> > >> >> In short, nice kernel tasks people with C language skills can do in few > >> >> evenings. > >> >> > >> >> https://wiki.freebsd.org/JuniorJobs > >> >> > >> >> It is assumed you know how to obtain sources and build the kernel. > >> >> > >> >> What you can get in return: > >> >> - your own code in FreeBSD tree > >> >> - eternal glory  > >> >> - fun  > >> >> > >> >> If you are not interested, but know someone who does, please pass it > >> >> down. > >> >> > >> >>  - not really, no > >> >>  - well, I guess that's subjective, so that's not a "no" > >> > > >> > Even though our bugmeisters have decided that we should not have wishlist > >> > items in our bug tracker, I really wish we could store the various idea > >> > lists > >> > (we have several) in an issue tracker instead. This would allow for > >> > folks to > >> > comment on ideas, vote for them, etc. It would also make it easier for > >> > more > >> > people to submit new ideas. > >> > > >> > >> Speaking not strictly with the bugmeister hat, but from experience, please > >> do > >> not let us go down the road of (ab)using a bug tracking solution as task > >> and > >> idea management system. I think that using the tasks feature of phabricator > >> (our reviews instance) would provide better workflow support for those > >> things, > >> starting out from sketching out rough ideas, discussing them, breaking > >> them up > >> in seperate tasks (linked to and dependent on each other) and collaborating > >> on them (take a look at https://developer.blender.org/T42339 for a > >> brief example). > >> > >> Having said this, let's keep the bug tracker a bug tracker. > >> > >> Cheers > >> Marcus > >> > >> > >> _______________________________________________ > >> freebsd-hack...@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > >> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > > > > I disabled the tasks on phabricator to avoid having it a duplicate of > > bugzilla, > > but if we have a use for it I can activate it! > > > > Actually I do like the idea of the bug tracker aka bugzilla being only for > > bugs > > and uxe phabricator for tracking the tasks > > having disparate trackers for "wishlist" and "bugs" is quite harmful > and splits the conversations. It makes people learn multiple systems > and search multiple places - especially if the feature ends up being > submitted as a patch to the bug tracker.
We have this situation right now with reviews and the bug tracker. reviews is used by the committers only right now, and both loosely interact with each other. Opening reviews to the public won't improve the situation of having two disparate systems to look into. Same goes for the Wiki and bug tracker, mailing lists, etc. The more relevant question thus would be: how do we point people to the correct location and at which point of time? This will call for a more tight integration in the foresesable future (e.g. search abilities for reviews, that can be triggered from the bug tracker and vice versa). > I'd rather keep wishlist items in the bug tracker than split them into two. > > (also, fwiw, I'd rather keep the tasks number space clean should we > ever decide to import from bugzilla -> phabricator) > Fair enough. If we are going to do that, the area however should be separate from typical "bugs", so people do not confuse wishes with bugs and vice versa. Also, to avoid long and misleading comment trails, we would need the ability to hide/remove errornous (bug-related) comments in the wishlist (a feature wished for independent of this, but a necessary prerequisite [probably coming soon]). Wishlist items thus should not belong to a currently existing product or component, but should be clearly classified in an own product and/or component category. Except from that, what else would be required and desired to have a suitable wishlist? The bug tracker right now features: - tags - keywords - links to internal bugs/items (dependencies and blockers) - links to external systems - links to svn commits and reviews - attachments - flags to request/confirm/deny things Cheers Marcus
Description: PGP signature