Re: [boost] [Boost-users] Maintenace Guidelines wiki page

Subject: Re: [boost] [Boost-users] Maintenace Guidelines wiki page
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-11-25 02:33:53

Hi,

please quote to who you are replying.

----- Original Message ----- 
From: "Tomas Puverle" <Tomas.Puverle_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, November 25, 2008 6:17 AM
Subject: Re: [boost] [Boost-users] Maintenace Guidelines wiki page

> 
>> Do you actually think the current peer review process is meaningless,
>> due to the fluidity of our operations?
>>
>> I wish I could get someone to just start composing a page of best
>> practices without jumping headlong into trying to impose constraints on
>> our contributors.  We haven't even tried making such guidelines
>> available yet.
> 
> I think one of the issues why we may be seeing a problem is that boost is a 
> different library than it was a few years ago.
> The number of new libraries has grown significantly and some of them are 
> becoming quite high level and domain specific.
> However, most new libraries don't get much exposure until they are 
> officially released by boost and as such are subject to more change than 
> older, more established libraries.  That in turn also means that new 
> libraries should be allowed more flexibility in their evolution, as their 
> user base is smaller.
> Dave Handley and I have already mentioned this a few times in one of the 
> other threads but nobody really responded.  Daniel Walker also suggested a 
> model similar to what Debian or Ubuntu do, which has some similarity, so I'm 
> trying to resurrect it the idea.
> I think the guidelines should be ultimately tied to the concept of the 
> "stable" versus "evolving" libraries.
> 
> Here's the original post describing the perceived advantages of this 
> approach:
> 
> http://article.gmane.org/gmane.comp.lib.boost.devel/182741/match=core

IMO, the guidelines match quite well with your concept of "stable" libraries. 
DW :"All changes to "stable" have to go through a review and cannot be brought in a single release - they must be deprecated and a migration path provided."

In the guidelines I'm writing I want to give some good practive that make a library stable, i.e. don't breack user code, this seems very important for a lot of people. Don't forget my first question before starting this guidelines. 

VBE: " I would like to know first which are the current criteria for acceptance of library modifications, in order to make a clear difference on what *must* be done and what *could* be done. Can some one point me to some written document?"

DA: "There are no set criteria.  All modifications are at the discretion of
the library maintainer."

The single difference between the guidelines and the "stable" library concept is that some of these "guidelines" are "rules" instead. BTW, I'll add the migration path on the guidelines.

Write these good practice in the form of "Guidelines" will be IMO a good starting point. The time been, good practices that are widely shared becomes often 'de facto' rules.

Best,
Vicente