On 11/20/2014 07:41 AM, Jonathan Ludlam wrote:
This seems like a very good start to the proposal. A few questions/statements:
- What would you require in terms of distribution resources? I'm assuming
git/koji access, so that you could build and distribute sig packages.
That sounds right.
1a. Would you require a mailing list or forum area?
I think a mailing list would be helpful. Personally I'm less bothered by the forum area, but others may disagree.
- What do you envision for release planning? Tracking upstream builds vs a
newer stabilized release?
I would imagine this decision being taken on a case-by-case basis. For critical things such as the compiler and some of the core libraries we may want to take the releases only after they've stabilised in the community for a while - e.g. the 4.02.0 release had a number of issues that 4.02.1 addressed, so we should be conservative in areas like this. For projects that are less mature, it may make more sense to simply track the releases as they happen.
- How would releases be built/scheduled? Build every month, every 6
months, "when something happens upstream" ?
Things happen upstream quite rapidly at the moment, so that would be too frequent. I suspect a monthly cadence would be right to begin with.
In thinking about this a bit more (and based on the pace of upstream you mention), it seems like this might be something which could be done via software collections. That way if there's a compatibility break for some reason, users would be able to have both an older and current version. Would you be willing to do this as part of a software collection?