> On 5 Apr 2016, at 7:03 PM, Christoph Berg <m...@debian.org> wrote: > > Re: Adrian Vondendriesch 2016-04-05 <57034dc7.5050...@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@clusterlabs.org > http://clusterlabs.org/mailman/listinfo/developers _______________________________________________ Developers mailing list Developers@clusterlabs.org http://clusterlabs.org/mailman/listinfo/developers
