[waffle] Checking In

Jordan Justen jljusten at gmail.com
Fri Oct 24 15:27:08 PDT 2014


On Fri, Oct 24, 2014 at 9:23 AM, Chad Versace
<chad.versace at linux.intel.com> wrote:
> On Wed 22 Oct 2014, Emil Velikov wrote:
>> On 11/09/14 15:43, Chad Versace wrote:
>> > On 09/07/2014 05:37 PM, Jordan Justen wrote:
>
>> > Having a year between 1.3 and 1.4, I'm reluctant to introduce delays.
>> > To avoid
>> > delays like that in the future, I'm thinking that waffle should adopt a
>> > short,
>> > time-based release cycle. Maybe every 4 to 6 weeks. With a cycle that
>> > short...
>> >
>> >     1. There would be no pressure to delays a release for a feature.
>> > Because
>> >        a new release is right around the corner.
>> >     2. If there's nothing interesting to release for a given cycle, then we
>> >        could just skip doing that release.
>> >     3. The release process would, by necessity of frequency, become mostly
>> >        automated. That automation would allow anyone (not just me) to do
>> >        a release.
>> >
>> > I haven't *decided* on any of the above. Just thinking that it may be a
>> > good
>> > idea. What do you think?
>> >
>
>> All of those sounds ok with me, yet I hope that the level of automation
>> is better than the one we have in mesa.
>
> I began writing a python script to fully automate that process. The
> script builds waffle, runs its testsuite, makes a git tag, creates
> a tarball and signs it, uploads everything, and then writes out
> a template announcement email.
>
> I should dig that script up, clean it up, and commit to the repo.

That sounds cool.

I wonder if it is something Emil could copy and tweak for piglit.

>> > So... let's try not to delay 2.0. And let's make releases more frequent.
>> > Then
>> > Emil's work on issue #9 will land quickly enough.
>> >
>>
>> Afaict one of your concerns may be bumping the library major version due
>> to the waffle_get_proc_address API change.
>> Admittedly I have not checked if piglit and the wfl utils will work if
>> we leave the interface as is and I'm planning to do so tomorrow. If
>> possible I'll avoid the API change, otherwise I might consider adding
>> another entry point in order to preserve backwards compatibility - ie.
>> waffle_get_proc_address2().
>>
>> Either one of those will get is in waffle-1.5 land which does not sound
>> as scary :P
>
> I would like to avoid breaking ABI compatibility unless the alternatives
> are really really bad. Because breaking ABI compatibility, being
> really^3 bad, is even worse than really^2 bad. I discussed introducing
> waffle_get_proc_address2() with Jordan in person, and (if I recall
> correctly), he was ok with the idea.

Yeah, I agree with you. It be nice to keep backward compatibility if possible.

-Jordan


More information about the waffle mailing list