Re: junior kernel tasks

On, Wed Oct 29, 2014, Eitan Adler wrote:

> On 28 October 2014 15:14, Baptiste Daroussin <bapt_at_freebsd.org> wrote:
> > On Tue, Oct 28, 2014 at 09:35:26PM +0100, Marcus von Appen wrote:
> >>
> >> Quoting John Baldwin <jhb_at_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 [1]
> >> >> - fun [2]
> >> >>
> >> >> If you are not interested, but know someone who does, please pass it
> >> >> down.
> >> >>
> >> >> [1] - not really, no
> >> >> [2] - 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-hackers_at_freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe_at_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