[Manoj Srivastava] [PATCH 2/4] [bug545548-srivasta]: Make upgradng-checklist a real HTML file

[Manoj Srivastava]

On Mon, Oct 05 2009, Bill Allombert wrote:

> On Mon, Oct 05, 2009 at 12:36:44AM -0500, Manoj Srivastava wrote:
>> Hi,
>>
>>         I have now updated the README docs with a slightly cleaner
>>  work-flow. I would like to get a show of hands from the policy team
>>  about this; and if people are OK with this approach (using org-mode,
>>  with perhaps me committing to maintaining these documents in the
>>  team), or abandoning this approach and going to plain old
>>  HTML/docbook.
>>
>>  Personally, I think that the .org files are easier to edit, even for
>>  people who are unfamiliar with org-mode, and are mroe readable than
>>  SGML based documents, and thus would have higher utility, but I'll
>>  abide with what the rest of the team thinks.
>
> How the synchronisation with the wiki will be handled ? Or is the wiki
> page deprecated ?

        The latter, I think.  But if people want to update the wiki pages
 I will not stand in the way.

> I still did not received any patches labelled [2/4].

        Well, I did:
Message-Id: <1254721008-21328-3-git-send-email-srivasta@...>

        Is there is a message size limit on the list? Patch 2/4 was 3585
 lines. Anyway, you can browse the full branch at:

http://git.debian.org/?p=dbnpolicy/policy.git;a=shortlog;h=refs/heads/bug545548-srivasta

        manoj
--
"Atomic batteries to power, turbines to speed." Robin, The Boy Wonder
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bill Allombert-3]

On Mon, Oct 05, 2009 at 03:05:42PM -0500, Manoj Srivastava wrote:

> On Mon, Oct 05 2009, Bill Allombert wrote:
>
> > On Mon, Oct 05, 2009 at 12:36:44AM -0500, Manoj Srivastava wrote:
> >> Hi,
> >>
> >>         I have now updated the README docs with a slightly cleaner
> >>  work-flow. I would like to get a show of hands from the policy team
> >>  about this; and if people are OK with this approach (using org-mode,
> >>  with perhaps me committing to maintaining these documents in the
> >>  team), or abandoning this approach and going to plain old
> >>  HTML/docbook.
> >>
> >>  Personally, I think that the .org files are easier to edit, even for
> >>  people who are unfamiliar with org-mode, and are mroe readable than
> >>  SGML based documents, and thus would have higher utility, but I'll
> >>  abide with what the rest of the team thinks.
> >
> > How the synchronisation with the wiki will be handled ? Or is the wiki
> > page deprecated ?
>
>         The latter, I think.  But if people want to update the wiki pages
>  I will not stand in the way.

In that case, I think it would be preferable to keep a single markup language
for the whole policy package.

Cheers,
--
Bill. <ballombe@...>

Imagine a large red swirl here.


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Manoj Srivastava]

On Mon, Oct 05 2009, Bill Allombert wrote:

> On Mon, Oct 05, 2009 at 03:05:42PM -0500, Manoj Srivastava wrote:
>> On Mon, Oct 05 2009, Bill Allombert wrote:
>>
>> > On Mon, Oct 05, 2009 at 12:36:44AM -0500, Manoj Srivastava wrote:
>> >> Hi,
>> >>
>> >>         I have now updated the README docs with a slightly cleaner
>> >>  work-flow. I would like to get a show of hands from the policy team
>> >>  about this; and if people are OK with this approach (using org-mode,
>> >>  with perhaps me committing to maintaining these documents in the
>> >>  team), or abandoning this approach and going to plain old
>> >>  HTML/docbook.
>> >>
>> >>  Personally, I think that the .org files are easier to edit, even for
>> >>  people who are unfamiliar with org-mode, and are mroe readable than
>> >>  SGML based documents, and thus would have higher utility, but I'll
>> >>  abide with what the rest of the team thinks.
>> >
>> > How the synchronisation with the wiki will be handled ? Or is the wiki
>> > page deprecated ?
>>
>>         The latter, I think.  But if people want to update the wiki pages
>>  I will not stand in the way.
>
> In that case, I think it would be preferable to keep a single markup language
> for the whole policy package.

        Then feel free to pick up the work, taking the language I have
 put in there. I'll keep the branch around, and perhaps even keep it
 updated. I am not interested in writing this up in debian-doc.

        But someone really should be writing this up, since the bug
 report was, in my opinion, on point: this stuff needs to be written up,
 and I think that the wiki stuff is already not as good as the README is
 when it comes to git process (far too many needless merges in that
 process).  If someone is willing to write this up and maintain it in
 debiandoc, great. Or else perhaps one could reconsider  my offer to
 maintain it in the current form.

        manoj
--
Auction: A gyp off the old block.
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Russ Allbery-2]

Manoj Srivastava <srivasta@...> writes:

>         But someone really should be writing this up, since the bug
>  report was, in my opinion, on point: this stuff needs to be written up,
>  and I think that the wiki stuff is already not as good as the README is
>  when it comes to git process (far too many needless merges in that
>  process).  If someone is willing to write this up and maintain it in
>  debiandoc, great. Or else perhaps one could reconsider my offer to
>  maintain it in the current form.

I'm fine to maintain it in org-mode.  I haven't played with it yet, but
I'm sure it can't be that hard, and it's not like the details change all
that much.

I think we're likely to move to Docbook in the long run, and when we do
that, we can look at rewriting it, but until then, I'm happy to use
whatever format whoever did the original work thinks is easiest to
maintain.  I probably would have used POD.  :)

--
Russ Allbery (rra@...)               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Manoj Srivastava]

On Sun, Oct 11 2009, Russ Allbery wrote:

> Manoj Srivastava <srivasta@...> writes:
>
>>         But someone really should be writing this up, since the bug
>>  report was, in my opinion, on point: this stuff needs to be written up,
>>  and I think that the wiki stuff is already not as good as the README is
>>  when it comes to git process (far too many needless merges in that
>>  process).  If someone is willing to write this up and maintain it in
>>  debiandoc, great. Or else perhaps one could reconsider my offer to
>>  maintain it in the current form.
>
> I'm fine to maintain it in org-mode.  I haven't played with it yet,
> but I'm sure it can't be that hard, and it's not like the details
> change all that much.

        Right.  Given that we do have a bug asking for this
 documentation, and that this is already written, and no one else has
 stepped up to re-write it in another format, I think I shall merge this
 branch in, at least as an interim measure. Given that this is not
 really policy, but packaging, we can always decide to change our mind.

> I think we're likely to move to Docbook in the long run, and when we
> do that, we can look at rewriting it, but until then, I'm happy to use
> whatever format whoever did the original work thinks is easiest to
> maintain.  I probably would have used POD.  :)

        Well, org-mode has a docbook output filter, so we can have a
 head start once we do convert. But I contend that org-mode markup is
 waaay easier to write than docbook xml (involves less typing), and is
 far more readable in raw format than XML is.  I did think about pod,
 but org-mode is far more powerful than pod is, and supports all kinds
 of things (built-in plain text spreadsheet, footnote support, various
 modes of URL, image support, etc -- all supported for various output
 formats). Also, I confess I am really really into org-mode, what with
 sing it in Ikiwiki and for my GTD agendas.

        manoj
--
Dare to be naive. Buckminster Fuller
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bill Allombert-3]

On Tue, Oct 13, 2009 at 10:23:29AM -0500, Manoj Srivastava wrote:

> On Sun, Oct 11 2009, Russ Allbery wrote:
>
> > Manoj Srivastava <srivasta@...> writes:
> >
> >>         But someone really should be writing this up, since the bug
> >>  report was, in my opinion, on point: this stuff needs to be written up,
> >>  and I think that the wiki stuff is already not as good as the README is
> >>  when it comes to git process (far too many needless merges in that
> >>  process).  If someone is willing to write this up and maintain it in
> >>  debiandoc, great. Or else perhaps one could reconsider my offer to
> >>  maintain it in the current form.
> >
> > I'm fine to maintain it in org-mode.  I haven't played with it yet,
> > but I'm sure it can't be that hard, and it's not like the details
> > change all that much.
>
>         Right.  Given that we do have a bug asking for this
>  documentation, and that this is already written, and no one else has
>  stepped up to re-write it in another format, I think I shall merge this
>  branch in, at least as an interim measure. Given that this is not
>  really policy, but packaging, we can always decide to change our mind.

Well I will do that, but first, I like to be remembered why the old
policy-process document has been removed.

Cheers,
--
Bill. <ballombe@...>

Imagine a large red swirl here.


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Manoj Srivastava]

On Tue, Oct 13 2009, Bill Allombert wrote:

> On Tue, Oct 13, 2009 at 10:23:29AM -0500, Manoj Srivastava wrote:
>> On Sun, Oct 11 2009, Russ Allbery wrote:
>>
>> > Manoj Srivastava <srivasta@...> writes:
>> >
>> >>         But someone really should be writing this up, since the bug
>> >>  report was, in my opinion, on point: this stuff needs to be written up,
>> >>  and I think that the wiki stuff is already not as good as the README is
>> >>  when it comes to git process (far too many needless merges in that
>> >>  process).  If someone is willing to write this up and maintain it in
>> >>  debiandoc, great. Or else perhaps one could reconsider my offer to
>> >>  maintain it in the current form.
>> >
>> > I'm fine to maintain it in org-mode.  I haven't played with it yet,
>> > but I'm sure it can't be that hard, and it's not like the details
>> > change all that much.
>>
>>         Right.  Given that we do have a bug asking for this
>>  documentation, and that this is already written, and no one else has
>>  stepped up to re-write it in another format, I think I shall merge this
>>  branch in, at least as an interim measure. Given that this is not
>>  really policy, but packaging, we can always decide to change our mind.
>
> Well I will do that, but first, I like to be remembered why the old
> policy-process document has been removed.

        Well, because it had become obsolete at the time it was
 removed. The old policy-process document was based on the work flow I
 created, and Russ streamlined the work flow and created the new policy
 process document, which is not obsolete (yet ;-).

        I further changed some git related steps in the process, to
 reduce unnecessary merges back and forth, and also to prevent loads of
 obsolete branches piling up in the public repository (look at gitk
 --all to see how recent changes are less confusing to follow), and that
 is the Process.{org,txt,html} document now included in the policy
 package.

        manoj
--
Waste not, get your budget cut next year.
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bill Allombert-3]

On Tue, Oct 13, 2009 at 01:15:04PM -0500, Manoj Srivastava wrote:

> On Tue, Oct 13 2009, Bill Allombert wrote:
>
> > Well I will do that, but first, I like to be remembered why the old
> > policy-process document has been removed.
>
>         Well, because it had become obsolete at the time it was
>  removed. The old policy-process document was based on the work flow I
>  created, and Russ streamlined the work flow and created the new policy
>  process document, which is not obsolete (yet ;-).
>
>         I further changed some git related steps in the process, to
>  reduce unnecessary merges back and forth, and also to prevent loads of
>  obsolete branches piling up in the public repository (look at gitk
>  --all to see how recent changes are less confusing to follow), and that
>  is the Process.{org,txt,html} document now included in the policy
>  package.

How are we supposed to build the package from the git repository now ?

Cheers,
--
Bill. <ballombe@...>

Imagine a large red swirl here.


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Manoj Srivastava]

On Tue, Oct 13 2009, Bill Allombert wrote:

> On Tue, Oct 13, 2009 at 01:15:04PM -0500, Manoj Srivastava wrote:
>> On Tue, Oct 13 2009, Bill Allombert wrote:
>>
>> > Well I will do that, but first, I like to be remembered why the old
>> > policy-process document has been removed.
>>
>>         Well, because it had become obsolete at the time it was
>>  removed. The old policy-process document was based on the work flow I
>>  created, and Russ streamlined the work flow and created the new policy
>>  process document, which is not obsolete (yet ;-).
>>
>>         I further changed some git related steps in the process, to
>>  reduce unnecessary merges back and forth, and also to prevent loads of
>>  obsolete branches piling up in the public repository (look at gitk
>>  --all to see how recent changes are less confusing to follow), and that
>>  is the Process.{org,txt,html} document now included in the policy
>>  package.
>
> How are we supposed to build the package from the git repository now ?

        Building the package from the git repo should still work. As
 long as the .org files are unmodified, the html files et al will still
 be in sync. If you modify the .org files, you need to install emacs23,
 and everything ought to work nominally.

        If there are problems, please let me know, these would be bugs
 that need fixing.

        manoj
--
LILO, you've got me on my knees! -- David Black, dblack@...,
with apologies to Derek and the Dominos, and Werner Almsberger
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...