xfs
[Top] [All Lists]

Re: Time for an xfsprogs "alpha1" release?

To: Mark Tinguely <tinguely@xxxxxxx>
Subject: Re: Time for an xfsprogs "alpha1" release?
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Thu, 12 Sep 2013 20:58:33 -0500
Cc: "'linux-xfs@xxxxxxxxxxx'" <linux-xfs@xxxxxxxxxxx>
Delivered-to: linux-xfs@xxxxxxxxxxx
In-reply-to: <523250E5.2050607@xxxxxxx>
References: <52322F7A.8060405@xxxxxxxxxxx> <5232380E.4040300@xxxxxxx> <52323DB7.8000800@xxxxxxxxxxx> <523250E5.2050607@xxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
On 9/12/13 6:40 PM, Mark Tinguely wrote:
> On 09/12/13 17:18, Eric Sandeen wrote:
>> On 9/12/13 4:54 PM, Mark Tinguely wrote:
>>> On 09/12/13 16:17, Eric Sandeen wrote:
>>>> With all of the changes for CRC filesystems in xfsprogs git now, I'm 
>>>> wondering if it'd be a good idea to do a "3.2.0-alpha1" sort of release.
>>>>
>>>> I know it's not yet feature complete, but I think there would be value in 
>>>> getting a version-stamped tarball out there for testing - it could filter 
>>>> to rawhide-ish distros, and get a bit more airtime while the remaining 
>>>> bits get worked out.
>>>>
>>>> We'd probably want a nice readme about what's new and what's not yet done, 
>>>> caveats, etc, but I think it'd be worth getting it out there into the 
>>>> hands of willing testers, w/o requiring them to do a build from git.
>>>>
>>>> Thoughts?
>>>>
>>>> Thanks,
>>>> -Eric
>>>>
>>>
>>> Good idea, but xfsprogs is in a state that it can't compile:
>>>
>>>     http://oss.sgi.com/archives/xfs/2013-09/msg00396.html
>>>
>>> Patch 31 v3 / 55 is broken. It is missing xfs_sb.c and has an extra
>>> xfs_mount.c.
>>>
>>> If you want it this week, we could do the corrections or wait for Dave
>>> to repost.
>>
>> hm? The git tree builds fine here, anyway (modulo some warnings).
>>
>> so quick, cut an alpha1 before it breaks.  ;)
>>
>> (but if you mean: we should get the latest stuff on the list in first,
>> and fix it so it builds - ok - but there will probably always be more
>> stuff to pull in, so at some point when we have a reasonable amount of it
>> in place, we could cut a test release?  There's always "alpha2"...)
>>
>> -Eric
> 
> Yep, simple to fix. I manually pulled in xfs_sb.c to make sure 47 v2 / 55 was 
> still okay. I can have a tar tomorrow.

Well, any released tarball needs to come from a tagged git tree, of course.

So if the new series needs to go in first, and needs fixes before that, we can 
wait.  Or if it's ok as it is now, and just missing some functionality, we 
could cut it now as alpha1, and cut alpha2 next.... *shrug*.  Not a huge rush, 
just pick a time when the tree is useful to get some wider testing, and cut a 
pre-release from that point in git.

-Eric

> --Mark.


<Prev in Thread] Current Thread [Next in Thread>