[Buildbot-devel] Developer Recruitment (summit topic)

[Marc-Antoine Ruel]

Le 22 novembre 2010 23:20, Dustin J. Mitchell <dustin at v.igoro.us> a écrit :

> I've made no secret of my desire to share responsibility for parts of
> Buildbot.  Currently, I see a lot of patch submissions, but in many
> cases bugs are found that I am ill-equipped to solve.
>
> My proposed approach is to formalize some of the roles and policies
> within Buildbot.  The idea is to break responsibilities down into
> manageable chunks that others can take on, and thereby parallelize
> Buildbot's development.  Here's my plan -- let me know what you think!
>
> First, break Buildbot into a collection of components - basically
> those in http://buildbot.net/trac/wiki/TicketKeywords, with some
> additions.  Each component will have at least one maintainer, with
> that information recorded in the source tree.  Components for which
> there is no maintainer and for which there are outstanding bugs will
> be scheduled for deletion after three releases with no maintainer.
> This should both pressure folks to step up to maintain components
> about which they are knowledgeable *and* clean out components that are
> unused.  We have a number of maintainers already - this will just make
> the relationship more formal.
>

That's great, I'm a big proponent of deleting stuff. :) Smell of XML-RPC
rotting... but we need strong alternatives, which doesn't fully exist yet in
that specific case. That's a subject for another thread.

At the same time, some things "just work" and don't really need any change
in general. For instance, we probably don't care there's perforce tickets, I
don't, unless someone goes ahead and fixes it. At the same time we won't
remove perforce support because nobody contributed in the past years. It
simply works "fine enough". I love "fine enough" software. So we should
continue having some "fine enough" components and just don't freak out
because there's bugs nobody wants to fix. We *can't* please everyone.

---

[OT]
I think not having to manage a server for buildbot.net is a feature. Unless
you find it easy for you and you don't mind doing it, then ignore the
following. I surprisingly prefer Google Code tracker than Trac, even if
everyone says Google Code's tracker sucks, it's really usable when you save
search queries and the summary display is way better IMHO since it's nicely
configurable. The wiki sucks in some ways but hey, you don't have to
maintain a server! Maybe I just used it too much and is biased. Please fork
this thread if you want to discuss this but I'm not sure it's even worth
since migrating would take too much effort. I think migrating to any free
hosted site is better than managing one but it's a only a long
term gain/cost. Feel free to disagree as I don't maintain buildbot.net (and
won't!). Spam, accounts, finding a server, bandwidth, yuck. Too bad github
doesn't have an issue tracker and wiki yet.


Next, recognizing that not everyone is an expert Twisted Python
> hacker, define a number of roles not limited to developers:
>  - core maintainer (who, among other things, will respond to pull requests)
>  - component maintainer
>  - tester (writing and/or running tests)
>  - packager
>  - buildbot.net admin
>  - trac admin (help me with ticket wrangling!)
>  - security incident handler
> (others?)
>
> Each of these would come with various permissions.  This basically
> gives me a set of rules to say who gets commit rights, who gets root
> on buildbot.net, who gets +v in #buildbot, etc., rather than making it
> arbitrary.  For the moment, I intend to be the one assigning roles to
> people.
>
> I welcome your thoughts.  Am I over-engineering things?  What else can
> I do to make the project more amenable to distributed authority?
>

I think you're over splitting it. For instance, I know Status(Push|Json)
stuff so I'm basically the owner of that area, having written almost 100% of
it. A component is orthogonal to handling tests or handling relevant
tickets. To me, core maintainer (e.g. dictator) + packager +
buildbot.netadmin = one person. Guess who? :P

As most contributors, we do it on our spare time, fighting our manager,
potentially at the cost of potentially not being promoted. I think
distributed authority doesn't work. It just creates bystander effect. It's
simpler if only one person has the last word. As for more administrative
tasks, I guess the more it can be automated, the more it can be delegated.
E.g. not create the administrative tasks in the first place.

M-A
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20101123/5b689705/attachment.html>