The kernel's code of conduct, one week later

Posted Sep 26, 2018 23:18 UTC (Wed) by airlied (subscriber, #9104)
In reply to: The kernel's code of conduct, one week later by johannbg
Parent article: The kernel's code of conduct, one week later

Like we already have had for years. The rules for getting patches into each subsystem is different, the rules for filing bugs with each subsystem is different. We'd like to try and get those things consolidated as well, but there are still outliers in all areas. The CoC isn't special here.

The kernel's code of conduct, one week later

Posted Sep 26, 2018 23:42 UTC (Wed) by johannbg (guest, #65743) [Link] (9 responses)

So why dont people stop trying and just act?

The kernel's code of conduct, one week later

Posted Sep 26, 2018 23:57 UTC (Wed) by airlied (subscriber, #9104) [Link] (8 responses)

They have acted, we have a CoC now. One subsystem had one, and now they all have it.

If you mean around other rules, well we have got coding standards and other rules we expect. Linus wrote git but not every subsystem maintainer uses it (akpm) and not every subsystem maintainer uses it consistently. Unilateral action is hard, but in some cases makes sense and can be done.

The kernel's code of conduct, one week later

Posted Sep 27, 2018 17:38 UTC (Thu) by johannbg (guest, #65743) [Link] (7 responses)

It's not limited to rules or guidelines what I was referring to.

Fragmentation in whole is bad so you dont want to have guidelines/rules/coding standards/documentation/bug trackers etc per sub-community and scattered across the internet because then for example you start waisting current and potential contributors time. A time that most communities either dont have or cannot afford.

The kernel's code of conduct, one week later

Posted Sep 27, 2018 19:11 UTC (Thu) by jani (subscriber, #74547) [Link]

The DRM subsystem is part of both the kernel and graphics communities. It's too simplistic to say deviating from some kernel rules or tools is automatically bad fragmentation. From the graphics community perspective there's plenty of synergy in using common freedesktop.org infrastructure; that's where our git repositories, mailing lists, bug trackers, etc. are hosted. For example, it's much more common to reassign bugs between graphics kernel and userspace than between graphics and the rest of the kernel. Many developers work in both spaces. Arguably the graphics community could not afford the fragmentation imposed by a split between kernel and userspace communities.

Due to the freedesktop.org infrastructure the DRM subsystem was de facto operating under the freedesktop.org code of conduct anyway, so formalizing it in DRM subsystem documentation was a natural progression. (And even so, more than two dozen acks by maintainers and developers were sought before committing.)

The kernel's code of conduct, one week later

Posted Sep 28, 2018 7:02 UTC (Fri) by marcH (subscriber, #57642) [Link] (5 responses)

> Fragmentation in whole is bad so you dont want to have guidelines/rules/coding standards/documentation/bug trackers etc per sub-community and scattered across the internet because then for example you start waisting current and potential contributors time.

Fragmentation is bad; one size doesn't always fits all either. The kernel is big. Different (mandatory) coding standards for different components does waste time, whereas different bug trackers does not much and it can have some benefits.

The kernel's code of conduct, one week later

Posted Oct 2, 2018 23:14 UTC (Tue) by johannbg (guest, #65743) [Link] (4 responses)

You can achive the point you are making without having to fragment but using multiple systems to maintain the origin comes at higher time cost due to the added complexity it brings.

If we use bug trackers as an example you need a single bug tracker as an origin and that bug tracker can have as many other bug trackers as can be imagine for as long as those bug trackers perform bi-directional communication amongst themselves to maintain that origin.

For example if an report is created in bug tracker at point of origin it will also be created at all or just the relevant sub-community bug tracker instance ( depending how this is setup ), any creation, state change,comment etc from the bug tracker at sub-community will also create,update etc report at the origin ( or pull/push model like used in dvs could be used ) .

The above is not fragmentation.

Fragmentation occures when there exist no bi-directional communication between bug trackers so if an report is created at origin the reporter is directed somewhere else to another bug tracker to create report there.

In addition to that, fragmentation exist in most peoples perception of time ( often used as false justification for having seperated instances from the origin, like seperated bug trackers ), in which it manifests itself by people putting more value on their time compared to others ( often via roles like developer vs reporter or doctor vs nurse etc which creates even further fragmentation and inevitable conflict ) when in fact we ( as in the entire human race ) are bound by the same amount of time, defined by the average lifespan of an human being.

bug tracker fragmentation

Posted Oct 4, 2018 3:43 UTC (Thu) by marcH (subscriber, #57642) [Link] (3 responses)

- I've seen a number of bug tracker "bridges" in operation and heard of a few more. They were all mostly dysfunctional and universally hated. A well designed schema for a bug database models closely the workflows of the corresponding team. Different teams work differently and bridging different schemas leaves users constantly wondering what exact information does the bridge lose and under which conditions.

- I can hardly see any value anyway in a unique bug tracker for the kernel - which again is a huge collection of many different projects. Why would the developers of some wifi driver care about bugs in some other random audio driver? Why would have to constantly filter out noise from other components? Why would they have to restrict themselves to a common and minimal schema? Why would they have to deal with the significantly higher administration complexity, work and permissions?

bug tracker fragmentation

Posted Oct 4, 2018 6:09 UTC (Thu) by johannbg (guest, #65743) [Link] (2 responses)

Through my life I have come across my share of various bug trackers and worked maintaining one for several years, which hosted over 1000 projects of mixed match of being software projects to request tracker, literally creating, and tailoring workflows to individual company and government structure,their departments, different teams to make those companies more efficent,meet their sla, generate reports etc.

I have seen unimaginable horror in this regard so much horror that I propably should make freedesktop.org my next draining the type ocean project and contribute to it's migration/restoration ( that is if it will ever get over it's identity crisis ) ;)

Anyway I understand the pain you are getting at but what you describe here is failure of the tool and or those that are administrating it, which is the cause of the fragmentation so simply switch out bugzilla for something better. . .

bug tracker fragmentation

Posted Oct 4, 2018 7:03 UTC (Thu) by marcH (subscriber, #57642) [Link] (1 responses)

Bugzilla is practically inexistent in the experience I described.

The tracker software certainly plays a role but not the most important role in my experience. How you configure and use it matters much more. it's a bit like programming languages: you can write bad code in any of them. It's just easier with some.

bug tracker fragmentation

Posted Oct 4, 2018 7:27 UTC (Thu) by johannbg (guest, #65743) [Link]

If bugzilla aint that bad then there is no excuse for kernel and all it's sub-communities not using it but I personally dont recommend it. Today's requirements are so much more then an simple bug tracker.