In an ideal world (according to me),
- we should follow the Apache models or precedents since they seem to
work for a large number of Apache projects.
- the individual projects would have their own committers who may or may
not commit to the core or framework. Perhaps someone can look into how
Apache handles access control to source repos when there are sub-projects.
- the sub-project would release their new versions separately from the
framework and core with a warranty that it works with the versions of
the core and framework which the sub-project has tested. The core and
framework team would not be responsible for testing or warrantying the
sub-projects. This does not mean that they should be reckless in
removing supported features without asking the sub-projects for comments
or being flexible about regressing changes that affect other projects.
Once a new version of the core and framework are released, it would be
up to the sub-projects to support it. This may slow adoption of new core
and framework releases but the users can support the sub-projects that
they need if they can't stand the wait. At least the core and framework
can get released without waiting for each sub-project to be updated and
tested.
- the core and framework projects should look for ways to clearly define
the API or interface points that the sub-projects should use.
- the core and framework team(s) would receive requests (JIRA issues)
from the sub-project for required changes that the sub-projects need to
advance their modules and make the changes in a release that would
permit the module to add the features. Having people who work on the
framework, the core and the sub-project is going to give some projects a
stronger position but "c'est la vie". This may be an incentive for new
people to take an active interest in maintaining some parts of the core
or framework for which they spend a lot of time writing JIRA issues.
- the sub-project would make its own roadmap and maintain its own
section(s) in the wiki.
- sub-projects would manage their own meritocracies that might have a
completely different criteria that the current group (someone who is a
strong player in the project management community - lecturer, author,
consultant with no programming skills could be a very important
contributor but you would not value them highly in the framework or
core. ). Realistically, as we see from the current discussion, the
initial thought leaders are going to come from the people who built
these things in the first place.
This would simplify the work of the core and framework team and allow
them to release more frequently and to focus on the central tasks
without having to worry about all the modules.
It will also allow each of these sub-projects to "market" their projects
with more certainty and more focus.
Ron
On 27/11/2014 1:41 PM, Jacopo Cappellato wrote:
This is a good point. We could find a way to programmatically enable/disable
the components just for the test run:
./ant -Denable-all=true clean-all load-demo run-tests
but this is just an idea; we could figure out the best way to go.
Jacopo
On Nov 27, 2014, at 7:14 PM, Adrian Crum <[email protected]>
wrote:
Be aware that disabling a component does two things:
1. Speeds up unit tests because the disabled component is excluded from them.
2. Increases the chance of regressions because the disabled component is not
being tested.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 11/27/2014 5:41 PM, Jacopo Cappellato wrote:
On Nov 27, 2014, at 6:25 PM, Jacques Le Roux <[email protected]>
wrote:
Yes, so we need to define which are those components. So 3 points, which should
be discussed separately it seems, not sure of the order yet but probably this
one
1) Components to move to Attic. They will be freezed but still available in
this state in Attic (in other words slowly dying)
2) Components to disable. They will be maintained, but OOTB will not interfere
with other components (applications or other specialpurpose)
3) Components to keep enabled. They must be maintained and have no interactions
with other components
Components enabled and disabled must be maintained in the same way: it is not
that a group is more important than the other.
Also, disabling a component doesn't mean that it will not go in a release: we
could have disabled components in releases and enabled components excluded from
a release or vice versa.
For the point 2 we need to clarify if it could applies to trunk also. I'd now
tend to avoid differences between trunk and branch releases, at the
functionality or other levels.
I agree that the same settings should be maintained in the trunk and in the
release branches.
Jacopo
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
