Re: [eclipse-pmc] Concerns Regarding Sub-Project Merege

["Daniel Megert" <daniel_megert@xxxxxxxxxx>]

> Lars offered himself
as a counterexample. I'd like to offer myself as a second. 

Did you use the fast track? No.

Dani



From:      
 Stefan Xenos <sxenos@xxxxxxxxx>
To:      
 eclipse-pmc@xxxxxxxxxxx
Date:      
 22.06.2017 17:14
Subject:    
   Re: [eclipse-pmc]
Concerns Regarding Sub-Project Merege
Sent by:    
   eclipse-pmc-bounces@xxxxxxxxxxx

---

IMO, merging the projects is incredibly important for
the survival of the Eclipse project as a whole. The barrier for entry when
moving between sub-projects is intense, and I have absolutely had situations
where I wanted to work on something in another component but held off because
of these barriers.

Dani mentioned SWT as an example of a place where we probably
wouldn't get new contributors. Lars offered himself as a counterexample.
I'd like to offer myself as a second. I wrote the pseudocode for GridLayout,
the deferred layout system, and the SWT layout caching system which Veronika
and Steve used as the basis for the current implementation. I understand
the algorithms in depth. I've wanted to contribute additional major
features for years (such as Android-style automatic layouts, proper size
computations for CTabFolder, a faster algorithm for computing minimum scroll
regions in ScrolledComposite, better computations for the preferred sizes
of spanning controls in GridLayout, and more), but held off due to the
difficulty of getting SWT commit rights. If the projects had been
merged, I would have been contributing major features to SWT for years.

As for assigning responsibility and accountability, I'd
suggest adopting a lightweight OWNERs system like chromium uses:

https://meowni.ca/posts/chromium-owners/

OWNERS is just a file you stick in any folder indicating
the usernames of who is accountable for its contents and subfolders. They
apply recursively. The scope of owners can be a single folder or an
entire project, and the scopes can change dynamically based on the current
set of contributors... so you can still have a formal code ownership system
with the following advantages:

- The process for moving owners around is much more lightweight
(it's just a patch to an OWNERS file that gets approved by the existing
owners - no need for additional committer elections)
- There is more flexibility for the scope of ownership.
We don't need to lock off an entire git repository if there's just one
package that has security concerns or requires special skills.
- OWNERS files are machine-readable, so you can build
additional tooling on top of them if desired.

The projects can be merged from a process, documentation,
tools, and permissions point-of-view without the need to sacrifice formal
accountability.

I'd suggest merging the projects, switching to an OWNERS
system, and putting an OWNERS file at the root of every repository containing
the current names of the project leads. Anyone else can create OWNERS files
for the code they normally work on, and you can add yourself to any OWNERS
file by submitting a patch and getting it reviewed by one of the current
owners.

Although merging the permissions will be the main benefit
of merging the projects, Eclipse should also be aiming to make it easy
to move between git repositories in other ways:
- Unify the development practices
- Standardize commit comment format
- Standardize the code style
- Standardize the way of tagging bugs in bugzilla and
requesting reviews
- Standardize the developer setup steps
- Standardize the build process
- Unify the mailing lists
- Put the documentation all in one place

The easier it is to move between subprojects, the more
people will do so... and merging the projects is a first big step to getting
there.

  - Stefan
_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc