Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-pmc] Concerns Regarding Sub-Project Merege

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:

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

Back to the top