[Dancer-users] Dev and Release workflow ( was: Re: Invalid value for log config )

damien krotkine dkrotkine at gmail.com
Sat Dec 18 15:10:17 CET 2010


On 18 December 2010 10:55, sawyer x <xsawyerx at gmail.com> wrote:

>
> On Fri, Dec 17, 2010 at 4:00 PM, damien krotkine <dkrotkine at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.backup-manager.org/pipermail/dancer-users/attachments/20101218/dd057964/attachment-0001.htm>


More information about the Dancer-users mailing list