[Debian-ha-maintainers] [ClusterLabs Developers] SBD Releases

[Andrew Beekhof]

> On 5 Apr 2016, at 7:03 PM, Christoph Berg <myon at debian.org> wrote:
> 
> Re: Adrian Vondendriesch 2016-04-05 <57034DC7.5050405 at credativ.de>
>> On 05.04.2016 06:21, Andrew Beekhof wrote:
>>> Its not a particularly high volume project, so for RHEL we've been sufficiently happy with hash based tarballs.
>> 
>> Ok, thanks for the reply. I think we will go this way, too.
> 
> Hi,
> 
> I've been browsing the commit history of sbd, and my impression was
> that there is much more going on than what I'd call "low volume".
> 
> The reason why Debian is usually asking for release tarballs is that
> we then have some "this version is ok for general use" statement from
> the authors, while for git-hash-snapshots, we can never really be sure
> that we haven't hit a spot that is WIP between two development
> sprints. Or a case of "there's this open pull request that should
> definitely be included, it's just not done yet". Or "the last commit
> in git HEAD does [not] warrant a new package release”.

All the work happens in private clones, the policy is that by the time it reaches the main repo it needs to be fully baked.

> 
> That said, we'd just need a tag on github, the tarball would then
> automatically be available in the /releases pages there. We could also
> point the new-upstream-version-available machinery there to get
> notified about new versions programmatically. (Driven by
> "debian/watch" files.)
> 
> To get the package started, we can of course use a snapshot tarball as
> Adrian said, but long-term I'd really prefer real releases. Would that
> be arrangeable?

We could possibly tag what’s going into RHEL if that would help.
I don’t know there is a lot of bandwidth going around to co-ordinate the testing required for full releases.

> 
> Thanks,
> Christoph
> 
> _______________________________________________
> Developers mailing list
> Developers at clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/developers