On 18 December 2010 10:55, sawyer x <xsawyerx@gmail.com> wrote:
On Fri, Dec 17, 2010 at 4:00 PM, damien krotkine <dkrotkine@gmail.com>wrote:
*top-posting*
OMG! :)
OMGZ!!!!111oneone :)
1/ About CPAN releases :
[...]
So I'm in favor for 1.2 and 1.3 being both stable versions. And only these to be released on CPAN.
Agreed! See my last reply on this subject (under the original topic).
I've checked on CPAN and it seems that it's not a problem to release 1.201 after 1.3 has been released. If you install a module from CPAN, you'll get the highest version by default. But if you ask CPAN the list of versions, you'll get them sorted by dates, which would work fine for us I think.
2/ About github :
[...]
Still seems like tricky business to me. Of course, I could be wrong. I think that once we remove the major backlog we'll be able to clean up the pull requests and branches nicely.
What I believe we need are reviewers. Basically nowadays I review everything and unofficially delegate things to Alexis, Franck, David, yourself, others. Most of these are either in inline responses to people (which isn't good because the intended reviewer could miss it) or on IRC/mail - not a very good way of doing it.
No one is actually an official reviewer that knows that what they do.
I agree to the extend that I think there are now 4 people (members of the core team) which are more and more seen as reviewer/integrators from the community, and that's good. Maybe there is a need of a bit more time and some communication on the ml and in the dev documentation, to make it more clear.
I think that if some people were just reviewers (even if it's just for specific stuff they know about), it'll be easier to skim through the pull requests and merge things better.
Also, if we'll be able to add new stuff and deprecate old behavior in the same release series (see your number 1 above, "About CPAN releases"), it'll be MUCH easier to integrate stuff. I'm still waiting on the forward() feature, for example.
Well, my opinion is that it's important to be strict with regards to versions : 1.2xx should be API compatible, as you said. So you can't deprecate and add features in these versions. However, maybe we need a shorter release cycle. While discussing on IRC, I mentioned one way of doing it : the release manager would aim at a time frame (say, a release every month). Nothing strict, but people know that they have to hurry to cleanup their code if they want their feature in the next release. And if their feature missed it, it's potentially only 1 month to wait, which is short enough. So they get motivated. Currently, there is no time frame, so you're not motivated to finish your feature, and you're a bit in the dark to know when a given feature will be included (like "forward"). That said, the release manager should have total control, and be able to say "it's too unstable, we'll release later", or "I remove these features, they are not good enough" About my "experimental" branch, after some discussion on IRC, I think it has be proven to be a bad idea. dams