Well, here's an 'doing it live' example for you. This is the parent issue
for our next release:

https://issues.apache.org/jira/browse/CB-5854

Its only adding one more step... which is or isn't a big deal depending on
how you look at it. (We have added that step btw.) Sometimes we ship
multiple times a month. Thats over 50 issues to close to do that. It's like
water torture; adding a drop isn't a big deal in itself but in aggregate it
will bore through your skull.

Working at Adobe I've learned a great deal about how 'just one more step'
isn't a big deal. We're not exactly characterized as nimble, effective,
efficient, or lean. That, to me, certainly is big deal.

Anyhow, this discussion most certainly has a foggy cultural aspect to
contrast with the direct returns in quality and predictability.





On Fri, Feb 14, 2014 at 1:23 PM, Niall Pemberton
<niall.pember...@gmail.com>wrote:

> I love the release cadence - more projects should do it - and I can
> understand why you fight anything that you believe would hinder that. But I
> don't really get how a vote affects that - whatever cycle you're on - it
> just shifts it 3 days? So if you were cutting a release on the last Friday
> of every month (for example) - nothing changes for the user except that the
> monthly release is available 3 days later - they still get it monthly, just
> on the Monday?
>
> Niall
>
>
> On Thu, Feb 13, 2014 at 3:25 AM, Brian LeRoux <b...@brian.io> wrote:
>
>> I'd like to throw out some thoughts in support of this thinking and help
>> explore how we can support faster releases at Apache.
>>
>> Cordova has bias to shipping. We started shipping on a schedule mid 2011
>> and this was a very deliberate choice, after two years of scattered, and
>> frankly reactionary, releases.
>>
>> At that time we called the project PhoneGap and we realized our offering
>> was playing cat and mouse with the very fast moving dependencies of iOS and
>> Android. Being reactionary made shipping a fire drill, inevitably drawn out
>> since we didn't exercise those muscles enough, and ultimately this made our
>> software a risk for adoption. We didn't want to be a risk for adoption. We
>> also did not want our volunteer committership killing themselves every time
>> iOS or Android landed a patch.
>>
>> Moving to a schedule acted as a forcing function to exercise those
>> muscles, find our cadence, and only positives to the code and community
>> resulted. Shipping brought our core together. It meant if we didn't have a
>> fix for a feature the branch would land in the next release which is only a
>> month away. This built huge confidence in our team by our community. Our
>> code become better tested, and more streamlined. A consistent release
>> cadence not only helped us find more quality in our code, but that
>> confidence really helped us build our committer and developer community.
>> The story is hardly unique: Chrome, Ubuntu, Docker, Firefox, and many
>> others have adopted this model in recent years.
>>
>> I feel anything that can be considered a better practice for higher
>> quality code and driving community confidence, and subsequently adoption,
>> really embodies Apache ideals.
>>
>> The current process could be largely automated and the vote doesn't
>> necessarily have to be in the form of an email. I've found these past weeks
>> the act of voting seems near cultural at Apache so I hope that doesn't
>> sound crazy! I mean well.
>>
>> Another issue I am personally unclear on is the wide variety of artifacts
>> destinations that an Apache project can be shipped today. Maven has some of
>> these smarts built in but projects like the npm registry do not. Another
>> area we need to address is the proliferation of various app stores. I'm not
>> a fan of them, but they happen, and we should have a mechanism for our
>> projects to deliver to them.
>>
>>
>> On Fri, Feb 7, 2014 at 3:02 AM, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>>> One of the projects I am involved with is the Jenkins project. At
>>> Jenkins we cut a release of Jenkins every wednesday... assuming the test
>>> all pass...
>>> Not every release is as stable as people might desire (the tests don't
>>> catch everything), hence there is the LTS release line, but none the less,
>>> there is a major release every 7 days... and if you look at the usage stats
>>> (e.g. http://stats.jenkins-ci.org/jenkins-stats/svg/201312-jenkins.svg)
>>> most users actually stick fairly close to the latest release.
>>>
>>> I have found that this 7 day release cadence can be really helpful for
>>> some code bases.
>>>
>>> When I started to think about could we follow this model for the Maven
>>> project as we move towards Maven 4.0, there is one thing that gets in the
>>> way... namely release votes.
>>>
>>> The standard answer is that we could publish snapshots... but those are
>>> not indented for use by users... and where the cadence can help is that
>>> these things can be picked up by users.
>>>
>>> So what is it that gets in the way with release votes:
>>>
>>> * The 72h "soft" requirement for vote duration
>>>
>>> * The actions that a PMC member is required to perform before they can
>>> vote. See http://www.apache.org/dev/release which states:
>>>
>>>     > Before voting +1 PMC members are required to download the signed
>>> source code package, compile it as provided, and test the resulting
>>> executable on their own platform, along with also verifying that the
>>> package meets the requirements of the ASF policy on releases.
>>>
>>> So how exactly do these things get in the way?
>>>
>>> Well as I see it the 72h vote duration isn't necessarily a big deal...
>>> we need some duration of notice about what is going into the release, there
>>> will always be people who feel the duration is either too short or two
>>> long... but with a 7 day cadence and maybe a few hours before the release
>>> manager closes out the vote and then you wait for the release to finished
>>> syncing to the mirrors and then the release manager gets a chance to verify
>>> that the release has synced to at least one mirror... you could easily lose
>>> half a day's duration in that process... oh look the release is out 3.5
>>> days after it was cut... and we're cutting another one in 3.5 days... it is
>>> likely we will not get much meaningful feedback from users in the remaining
>>> 3.5 days... so essentially you end up with a ping-pong of break... skip...
>>> fix since if a bleeding edge user finds an issue in 4.0.56 we will have cut
>>> 4.0.57 by the time they report it to us and the fix ends up in 4.0.58...
>>> with a shorter vote duration, say 12h, the bleeding edge user reports the
>>> issue, we fix and the next release is the one they can use.
>>>
>>> In the context of a fast cadence, where every committer in the community
>>> knows there will be a release on wednesday cut from the last revision that
>>> passed all the tests on the CI system unless there have been no commits
>>> since the last release that meet that criteria, do we need to wait the full
>>> 72h for a vote? Would 12h be sufficient (assuming the 3 PMC +1's get cast
>>> during those 12h... and if not, well just extend until enough votes are
>>> cast)
>>>
>>> I think this is different use case from my understanding of the concerns
>>> that drove the 72h vote duration convention, as this would not be 3 PMC
>>> members who all work for the same company and are in the same location
>>> conspiring to drive their changes into the release... everything would be
>>> happening in the open and a 12h window mid-week should allow at least 4h of
>>> waking time in any TZ.
>>>
>>> So the second issue is what a PMC member is required to do before
>>> voting...
>>>
>>> As a PMC member you are required to
>>>
>>> 1. Download the source code package
>>>  2. Compile it as provided
>>> 3. Test the resulting executable on your own platform
>>> 4. Verify that the package meets the requirements of the ASF policy on
>>> releases
>>>
>>> Do we really have to personally do all that *by hand*?
>>>
>>> Why can we not have a trusted build server hosted on Apache hardware do
>>> the download of the source package, compile it as provided and run the
>>> automated acceptance tests (on a range of platforms), the RAT tooling and
>>> perhaps verify that the source code package matches what is in source
>>> control? The trusted build server could then report the results to the
>>> project mailing list and then the PMC members just need to confirm the
>>> build server said OK, review the commits between the last time they looked
>>> at the commits and the tag (which they know matches what is in the source
>>> bundle) and then vote +1?
>>>
>>> The PMC members are supposed to be keeping an eye on the commits anyway,
>>> so that shouldn't be too onerous, and the release manager could even
>>> provide a link to the build server confirmation build in the VOTE email.
>>>
>>> I would appreciate any people's thoughts on the above.
>>>
>>> -Stephen
>>>
>>> P.S.
>>> * Speaking in my personal capacity as a member of the ASF.
>>>  * I am not saying that Maven will move to such a model, or even wants
>>> to move to such a model... more that I was thinking about the issues that
>>> might prevent us if we so desired... I know other projects at Apache are
>>> interested in fast release cadence however, so getting this topic discussed
>>> in the open is no bad thing IMHO
>>>
>>>
>>
>

Reply via email to