[Rear-users] Project future
dag at wieers.com
Thu Nov 24 13:55:17 CET 2011
On Tue, 22 Nov 2011, Schlomo Schapiro wrote:
> I just met with Dag Wieers (one of the benfits of visiting Gent!) and we
> talked about some ideas for ReaR:
> - Move ReaR to github
> - Rework the website
> - get a proper domain for the project, like rear-project.org (which is
> still available unlike rear.com, rear.org ...). That way the next
> migration won't change the project website domain any more...
> Any feedback on these ideas? Any other suggestions for the new domain?
> Don't worry about the cost, I'll fund it.
A domain is not a necessity for me.
I see one issue when moving to Github. Github does not provide
mailinglists as it only centers around development and discussions on
Github integrate with email. So either we slowly replace the mailinglist
with issues/discussions on Github, or we have to find an alternative (stay
with Sourceforge for mailinglists ?).
For support I think both Github and mailinglist might impose a barrier
that some users are unlikely to overcome. Besides mailinglists offer
archiving capabilities that can help users find solutions more easily.
(Although I must say that Sourceforge doesn't integrate
mailinglists/archives very well to leverage them)
> If there won't be any objections (with good arguments), then I would
> consider these suggestions to be approved by the community.
No objections. In my mind I had already stipulated how the coming weeks
would look in preparation of a new release:
- Improve the documentation so it was release worthy
- Perform (manual) testing using a test matrix
- Prepare for release
Then when that release was done, I was planning the next steps:
- Restructure the development tree as discussed before
- Improving the website (and now maybe moving to github)
- Look at a way to automate testing better
(may include improvements to Rear to facilitate testing too)
- Perform require testing using a test matrix
- Prepare for next release
The above does not include any features or improvements, the releases seem
to be linked to project changes, but in fact they are not. I would like us
to make a list of things we would like to do:
- Working multipath support
- Working btrfs support
- Known bug #1
- Known bug #2
Each of these bugs/features can have one or more maintainers, which means
they are involved in the work (this allows others to known who to contact
A set of bugs/features can then be attached to milestones, there is a
certain flexibility so items can be postponed to the next milestone.
Fixed problems from a future milestone can be moved to the next
milestone. So the milestone can provide a clear picture of what is
necessary to have a new release, and policy/design decisions are more
obvious in the dicussion per feature/milestone.
In the case of releases that are mandatory to eg. a new Fedora release,
where the release process cannot quickly be started because the milestone
is not within easy reach, we could simply backport the functionality (if
possible) to the previous release (by means of a branch) which in the
recent case would have resulted in 1.11.1 instead of 1.12.
The above features/issues and milestones are an integrated part of Github.
You can see how it works here:
One can use colors/tags to group issues together.
-- dag wieers, dag at wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info at dagit.net, http://dagit.net/
[Any errors in spelling, tact or fact are transmission errors]
More information about the rear-users