[FEEDBACK] Governance of GlusterFS project

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



As one of the guys supporting this software, I agree that I would like 
bugfix releases to happen more. Critical and security bugs should 
trigger an immediate test release. Other bug fixes should go out on a 
reasonable schedule (monthly?). The relatively new CI testing should 
make this a lot more feasible.

If there weren't hundreds of bugs to examine between releases, I would 
happily participate in the evaluation process.

On 07/26/2013 05:16 PM, Bryan Whitehead wrote:
> I would really like to see releases happen regularly and more
> aggressively. So maybe this plan needs a community QA guy or the
> release manager needs to take up that responsibility to say "this code
> is good for including in the next version". (Maybe this falls under
> process and evaluation?)
>
> For example, I think the ext4 patches had long been available but they
> just took forever to get pushed out into an official release.
>
> I'm in favor of closing some bugs and risking introducing new bugs for
> the sake of releases happening often.
>
>
>
> On Fri, Jul 26, 2013 at 10:26 AM, Anand Avati <anand.avati at gmail.com> wrote:
>> Hello everyone,
>>
>>    We are in the process of formalizing the governance model of the GlusterFS
>> project. Historically, the governance of the project has been loosely
>> structured. This is an invitation to all of you to participate in this
>> discussion and provide your feedback and suggestions on how we should evolve
>> a formal model. Feedback from this thread will be considered to the extent
>> possible in formulating the draft (which will be sent out for review as
>> well).
>>
>>    Here are some specific topics to seed the discussion:
>>
>> - Core team formation
>>    - what are the qualifications for membership (e.g contributions of code,
>> doc, packaging, support on irc/lists, how to quantify?)
>>    - what are the responsibilities of the group (e.g direction of the
>> project, project roadmap, infrastructure, membership)
>>
>> - Roadmap
>>    - process of proposing features
>>    - process of selection of features for release
>>
>> - Release management
>>    - timelines and frequency
>>    - release themes
>>    - life cycle and support for releases
>>    - project management and tracking
>>
>> - Project maintainers
>>    - qualification for membership
>>    - process and evaluation
>>
>> There are a lot more topics which need to be discussed, I just named some to
>> get started. I am sure our community has members who belong and participate
>> (or at least are familiar with) other open source project communities. Your
>> feedback will be valuable.
>>
>> Looking forward to hearing from you!
>>
>> Avati
>>



[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux