Sounds great, Roman! I think we should also start defining guidelines and processes as well.
What is the current BigTop development cycle? Is the codebase frozen a certain period before release? I suggest that there be a pre-release build check before each release. If a component isn't building in the pre-release check, it is put on probation. If it is not fixed by release, it is not included in the release and all maintainers will be removed from that component. If a component is building but has no maintainers during release cycle n, it is put on probation. If no one steps up by release n + 1, the component is marked as unmaintained and dropped from the release. On Fri, Jan 16, 2015 at 1:04 PM, Roman Shaposhnik <[email protected]> wrote: > On Fri, Jan 16, 2015 at 9:52 AM, RJ Nowling <[email protected]> wrote: > > Hi BigTop, > > > > There has been a lot of discussion as to what the future BigTop would > look > > like. To my understanding, one of the drivers has been not having enough > > manpower to maintain all of the packaging and testing efforts for every > > component. Similar problems are faced by the Fedora and Debian > communities. > > > > Instead of an explicit kill or keep list, why not ask for volunteers who > > are willing to maintain specific components? If a component's > > maintainer(s) don't respond or review updates or build errors within a > > specific time frame, components would be put on "probation" status. If > > another maintainer doesn't volunteer, then the components are marked as > > unmaintained and dropped from the build. In the future, if someone wants > > to resurrect an unmaintained component, they can petition to do so and > the > > component can be put back on "probation" for a period of time. > > > > This is the approach the Fedora community uses. > > > > This will encourage folks to take ownership of components that are > > important to them, provide clear guidelines for keeping vs dropping > > packages, and solve the keep/drop debate organically. > > > > What do you think? > > Personally, I like the idea very much. I guess one way to go about it > is to start MAINTAINERS.txt with the current set of projects and let > folks assign them to themselves? > > Thanks, > Roman. >
