Re: manpages.debian.org has been modernized!
On Thu, Jan 19, 2017 at 4:43 PM, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
> Michael Stapelberg writes ("Re: manpages.debian.org has been modernized!"):
>> On Wed, Jan 18, 2017 at 11:37 PM, Ian Jackson
>> > Also, I think the exact running version of Debian services should be
>> > publicly available. And, unless this is made so easy that the service
>> > operators don't have to think about it, it will always fall behind.
>> > So I think this should be done automatically.
>>
>> All pages on manpages.debian.org already include the git revision at
>> the bottom of the page, e.g.:
>>
>> debiman c17f615, see github.com/Debian/debiman
>
> mariner:~> curl -s 'https://manpages.debian.org/cgi-bin/man.cgi?query=make&apropos=0&sektion=0&manpath=Debian+8+jessie&format=html&locale=en' | grep debiman
> mariner:~>
You’re querying the old software of manpages.debian.org which will be
turned down soon.
>
>> Hence, you can already check out the exact running version. Is that
>> not sufficient?
>
> I'm afraid not (even supposing that the lack of the commitid is just a
> bug). For a debian.org service, I would like to be able to check out
> the running version without interacting with a proprietary online
> service.
Would a mirror of the git repository on alioth be sufficient? I had
planned to set that up, but didn’t get around to it yet. Any help with
that would be very welcome.
>
> Also, what stops (answer might be workflow, technology, whatever) an
> operator who is in a hurry directly updating the running copy without
> pushing to github ?
People with the appropriate UNIX permissions (being part of the
“manpages” group) can of course always circumvent any workflow or
safe-guards which are put into place.
Personally, my intention is that the workflow ends up such that the
right thing happens. As the system is new and we’re just rolling it
out now, things are still a bit in flux.
In general, I hear your concern and would like to assure you that I am
working towards the goal of anyone being able to reproduce the exact
output that manpages.debian.org serves. If I fail in that endeavour
within the next month or so, please feel free to poke me again. Until
then, I’d like to ask you to allow us some time to get things settled.
>
> As I say, I don't want to impose more work on you because of my outre'
> ethical views. I would like to solve this problem by providing a
> patch that causes debiman to copy its source and its git history to
> its own output. That way you would have to do nothing.
To help me understand the implications of such a patch, can you point
me to an existing implementation of such a patch in another service
please?
>
>> > If we created a pseudopackage in the Debian bug system, would you use
>> > it instead ? It's one thing to use github as a generic git hosting
>> > server but I really don't want us to be constructing our issue tracker
>> > data in github's databases.
>>
>> I personally find the Debian bug system very uncomfortable to use. I
>> will begrudgingly accept reports made via the BTS, as I do for the
>> Debian packages I maintain. I don’t want to give up using GitHub’s
>> issue tracker, though, for my convenience and the convenience of our
>> users.
>
> Using github as well is up to you. I won't try to talk you out of it.
> But I think for a service in the .debian.org namespace, bugs should be
> reportable without interacting with a proprietary web service.
>
> So thank you for agreeing to work with a system you don't find
> comfortable. You'll see that I have filed a bug against b.d.o
> requesting the manpages.debian.org pseudopackage.
>
> Ian.
>
> --
> Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
>
> If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
> a private address which bypasses my fierce spamfilter.
--
Best regards,
Michael
Reply to: