Hi folks, Dan is right, and this approach is the best for us to minimize the overhead. There may however be some points of improvement to give the right visibility to users, and avoid the confusion of "things being visible on the website though not yet published as a release". not much details from my side on this for now, though... cheers, Arno 2016-06-07 0:50 GMT+02:00 hyouko at gmail.com <hyouko at gmail.com>:> hmm.. > In my opinion, since we try to keep the master branch of our main git > repo (nut) always up-to-date (i.e. we don't do development in a > separate branch and only merge it back into master when readying a new > release) and in a working condition, we should not keep the website > frozen between releases, we should, instead, fetch and publish updates > when needed: the website will then reflect the status of our > officially official (albeit not yet part of a set-in-stone release) > code -- if anyone wants a snapshot of the website at the time of a > given release, they it can be built from tags. > (..and, being the personification of laziness, I'd rather prefer to > avoid any possible conflict that a separate branch could generate when > merged back into master) >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20160607/f9f73f19/attachment.html>
On Jun 7, 2016, at 10:21 AM, Arnaud Quette <aquette.dev at gmail.com> wrote:> > There may however be some points of improvement to give the right visibility to users, and avoid the confusion of "things being visible on the website though not yet published as a release".Unfortunately, there are a few items in the DDL with unreleased NUT versions (v2.7.?-g????). Oh, well. However, this was not an error I was expecting to see when rebuilding: http://buildbot.networkupstools.org/public/nut/builders/Debian-website/builds/55/steps/shell/logs/stdio [...] Makefile:796: *** target pattern contains no '%'. Stop. Any ideas? Also, what do I do afterwards to push to GitHub? -- Charles Lepple clepple at gmail
> However, this was not an error I was expecting to see when rebuilding: > > http://buildbot.networkupstools.org/public/nut/builders/Debian-website/builds/55/steps/shell/logs/stdio > [...] > Makefile:796: *** target pattern contains no '%'. Stop. > > Any ideas?I think we don't support colons in names of files and dirs: - https://github.com/networkupstools/nut-ddl/commit/3a68bbdfc6e3274aad027707d71f8a77fdbaa12d - https://github.com/networkupstools/nut-ddl/commit/3861afc614490f2a626059514b47011c754bd27c Tomorrow (now I can't keep my eyes open) I'll address that: we can either add colons to the list of unsupported characters ( https://github.com/networkupstools/nut-ddl#a-message-to-you-rudy ) and rename those 2 files, or try to escape them - preferences?> Also, what do I do afterwards to push to GitHub?I think that it should be enough to rsync (deleting files not present in source dir from destination dir, but excluding '/.git/', '/CNAME', '/source/' and '/package/') the generated 'output' directory to the dir coupled with 'networkupstools.github.io' repository, go to that dir, git add/commit, then push to GitHub. Tangentially, I still think that we should move 'source' and 'package' dirs to their own repositories and add them as submodules of 'nut-website', then we will not need to ignore those two dirs and we should be able to generate indices for them and further automate the release process, something like this: https://github.com/zykh/nut-website/tree/source-package (with 'source' and 'package' added as dirs/submodules).