[gentoo-catalyst] Migrating man page to asciidoc?

[gentoo-catalyst] Migrating man page to asciidoc?

[Sebastian Pipping]

Hello!


According to git blame, the man page of catalyst hasn't been touched
since 2005.  I would like to migrate it to Asciidoc to ease up future
maintenance.  I would add a Makefile including  a "dist" target to make
sure we always ship releases with an updated man page.  The list of
supported subarches could be pulled into the man page automatically.

What do you say?

Best,



Sebastian

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Peter Volkov]

В Птн, 24/06/2011 в 02:41 +0200, Sebastian Pipping пишет:
> According to git blame, the man page of catalyst hasn't been touched
> since 2005.  I would like to migrate it to Asciidoc to ease up future
> maintenance.  I would add a Makefile including  a "dist" target to make
> sure we always ship releases with an updated man page.  The list of
> supported subarches could be pulled into the man page automatically.
> 
> What do you say?

For me if man page was not touched since 2005 means that it's completely
unmaintained and thus since you are interested in maintaining - just go
ahead!

BTW, thanks for your efforts.

--
Peter.

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Sebastian Pipping]

Hello!


Migration done:
- Man page source now asciidoc
- List of subarches generated and included
- Makefile added, targets:
  - all
  - dist
  - clean

http://git.overlays.gentoo.org/gitweb/?p=proj/catalyst.git;a=commitdiff;h=fa940f755fbe539ffdeed748df7f1e31d9427f72

Best,



Sebastian

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Matt Turner]

On Fri, Jun 24, 2011 at 1:16 PM, Sebastian Pipping <sping@gentoo.org> wrote:
> Hello!
>
>
> Migration done:
> - Man page source now asciidoc
> - List of subarches generated and included
> - Makefile added, targets:
>  - all
>  - dist
>  - clean
>
> http://git.overlays.gentoo.org/gitweb/?p=proj/catalyst.git;a=commitdiff;h=fa940f755fbe539ffdeed748df7f1e31d9427f72
>
> Best,
>
>
>
> Sebastian

I see that you've committed these changes to only the catalyst_2
branch, and not master. Will you commit them to master as well?

Matt

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Sebastian Pipping]

On 06/25/2011 07:30 PM, Matt Turner wrote:
> I see that you've committed these changes to only the catalyst_2
> branch, and not master. Will you commit them to master as well?

Yes, in a minute.


While we're at keeping things in sync: have you propagated your updates
to the list of subarches to the web page?  After running "make" you can
find updated GuideXML for copy-n-paste at ./doc/subarches.generated.xml.
 Admittedly, this change would be easy (or easier?) to do incrementally.

Best,



Sebastian

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Matt Turner]

On Sat, Jun 25, 2011 at 1:50 PM, Sebastian Pipping <sping@gentoo.org> wrote:
> While we're at keeping things in sync: have you propagated your updates
> to the list of subarches to the web page?  After running "make" you can
> find updated GuideXML for copy-n-paste at ./doc/subarches.generated.xml.
>  Admittedly, this change would be easy (or easier?) to do incrementally.

Just updated. Thanks for the python script. :)

Matt

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Matt Turner]

On Sat, Jun 25, 2011 at 1:50 PM, Sebastian Pipping <sping@gentoo.org> wrote:
> On 06/25/2011 07:30 PM, Matt Turner wrote:
>> I see that you've committed these changes to only the catalyst_2
>> branch, and not master. Will you commit them to master as well?
>
> Yes, in a minute.

I get this when trying to do `EGIT_BRANCH="catalyst_2" emerge
=catalyst-9999` I suppose because asciidoc isn't listed as a
dependency.

./doc/make_subarch_table_guidexml.py
a2x --conf-file=doc/asciidoc.conf --attribute="catalystversion=`fgrep
'__version__=' catalyst | sed 's|^__version__="\(.*\)"$|\1|'`" \
         --format=manpage -D files "doc/catalyst.1.txt"
/bin/sh: a2x: command not found
make: *** [files/catalyst.1] Error 127
emake failed

but I see that asciidoc has quite a number of dependencies.

[ebuild  N     ] media-libs/jpeg-8c  USE="-static-libs"
[ebuild  N     ] app-text/build-docbook-catalog-1.6
[ebuild  N     ] media-libs/libpng-1.4.7  USE="-apng -static-libs"
[ebuild  N     ] virtual/jpeg-0  USE="-static-libs"
[ebuild  N     ] dev-libs/libgpg-error-1.10  USE="nls -common-lisp
-static-libs"
[ebuild  N     ] app-text/sgml-common-0.6.3-r5
[ebuild  N     ] dev-lang/swig-2.0.4  USE="pcre -ccache -doc"
[ebuild  N     ] dev-util/gtk-doc-am-1.17
[ebuild  N     ] app-text/docbook-xsl-stylesheets-1.76.1
[ebuild  N     ] dev-libs/libgcrypt-1.5.0_beta1-r2  USE="-static-libs"
[ebuild  N     ] media-libs/gd-2.0.35-r3  USE="fontconfig jpeg png
truetype zlib -static-libs -xpm"
[ebuild  N     ] dev-libs/glib-2.28.8  USE="static-libs -debug -doc
-fam (-introspection) (-selinux) -test -xattr"
[ebuild  N     ] media-gfx/graphviz-2.26.3-r3  USE="nls perl python
-cairo -doc -examples -gtk (-java) -lasi -ruby -static-libs -tcl"
[ebuild  N     ] app-text/docbook-xml-dtd-4.5-r1
[ebuild  N     ] dev-libs/libxslt-1.1.26-r1  USE="crypt python -debug"
[ebuild  N     ] app-text/asciidoc-8.6.5  USE="-examples -highlight
-test -vim-syntax"

Is there some way we can slim this down? Presumably asciidoc isn't
going to be using any image-related programs for generating a man
page.

Matt

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Sebastian Pipping]

On 06/26/2011 04:02 AM, Matt Turner wrote:
> I get this when trying to do `EGIT_BRANCH="catalyst_2" emerge
> =catalyst-9999` I suppose because asciidoc isn't listed as a
> dependency.
> 
> ./doc/make_subarch_table_guidexml.py
> a2x --conf-file=doc/asciidoc.conf --attribute="catalystversion=`fgrep
> '__version__=' catalyst | sed 's|^__version__="\(.*\)"$|\1|'`" \
>          --format=manpage -D files "doc/catalyst.1.txt"
> /bin/sh: a2x: command not found
> make: *** [files/catalyst.1] Error 127
> emake failed

Correct, asciidoc is missing.


> but I see that asciidoc has quite a number of dependencies.
> 
> [ebuild  N     ] media-libs/jpeg-8c  USE="-static-libs"
> [ebuild  N     ] app-text/build-docbook-catalog-1.6
> [ebuild  N     ] media-libs/libpng-1.4.7  USE="-apng -static-libs"
> [ebuild  N     ] virtual/jpeg-0  USE="-static-libs"
> [ebuild  N     ] dev-libs/libgpg-error-1.10  USE="nls -common-lisp
> -static-libs"
> [ebuild  N     ] app-text/sgml-common-0.6.3-r5
> [ebuild  N     ] dev-lang/swig-2.0.4  USE="pcre -ccache -doc"
> [ebuild  N     ] dev-util/gtk-doc-am-1.17
> [ebuild  N     ] app-text/docbook-xsl-stylesheets-1.76.1
> [ebuild  N     ] dev-libs/libgcrypt-1.5.0_beta1-r2  USE="-static-libs"
> [ebuild  N     ] media-libs/gd-2.0.35-r3  USE="fontconfig jpeg png
> truetype zlib -static-libs -xpm"
> [ebuild  N     ] dev-libs/glib-2.28.8  USE="static-libs -debug -doc
> -fam (-introspection) (-selinux) -test -xattr"
> [ebuild  N     ] media-gfx/graphviz-2.26.3-r3  USE="nls perl python
> -cairo -doc -examples -gtk (-java) -lasi -ruby -static-libs -tcl"
> [ebuild  N     ] app-text/docbook-xml-dtd-4.5-r1
> [ebuild  N     ] dev-libs/libxslt-1.1.26-r1  USE="crypt python -debug"
> [ebuild  N     ] app-text/asciidoc-8.6.5  USE="-examples -highlight
> -test -vim-syntax"
> 
> Is there some way we can slim this down? Presumably asciidoc isn't
> going to be using any image-related programs for generating a man
> page.

The image stuff is indirect dependencies, see --tree.

Future releases of catalyst do not have this problem as the make file
comes pre-rendered with the tarball.  This is a live-ebuild issue.

Best,



Sebastian

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2900 bytes --]

On Sun, Jun 26, 2011 at 04:36:15AM +0200, Sebastian Pipping wrote:
> On 06/26/2011 04:02 AM, Matt Turner wrote:
> > I get this when trying to do `EGIT_BRANCH="catalyst_2" emerge
> > =catalyst-9999` I suppose because asciidoc isn't listed as a
> > dependency.
> > 
> > ./doc/make_subarch_table_guidexml.py
> > a2x --conf-file=doc/asciidoc.conf --attribute="catalystversion=`fgrep
> > '__version__=' catalyst | sed 's|^__version__="\(.*\)"$|\1|'`" \
> >          --format=manpage -D files "doc/catalyst.1.txt"
> > /bin/sh: a2x: command not found
> > make: *** [files/catalyst.1] Error 127
> > emake failed
> 
> Correct, asciidoc is missing.
> 
> 
> > but I see that asciidoc has quite a number of dependencies.
> > 
> > [ebuild  N     ] media-libs/jpeg-8c  USE="-static-libs"
> > [ebuild  N     ] app-text/build-docbook-catalog-1.6
> > [ebuild  N     ] media-libs/libpng-1.4.7  USE="-apng -static-libs"
> > [ebuild  N     ] virtual/jpeg-0  USE="-static-libs"
> > [ebuild  N     ] dev-libs/libgpg-error-1.10  USE="nls -common-lisp
> > -static-libs"
> > [ebuild  N     ] app-text/sgml-common-0.6.3-r5
> > [ebuild  N     ] dev-lang/swig-2.0.4  USE="pcre -ccache -doc"
> > [ebuild  N     ] dev-util/gtk-doc-am-1.17
> > [ebuild  N     ] app-text/docbook-xsl-stylesheets-1.76.1
> > [ebuild  N     ] dev-libs/libgcrypt-1.5.0_beta1-r2  USE="-static-libs"
> > [ebuild  N     ] media-libs/gd-2.0.35-r3  USE="fontconfig jpeg png
> > truetype zlib -static-libs -xpm"
> > [ebuild  N     ] dev-libs/glib-2.28.8  USE="static-libs -debug -doc
> > -fam (-introspection) (-selinux) -test -xattr"
> > [ebuild  N     ] media-gfx/graphviz-2.26.3-r3  USE="nls perl python
> > -cairo -doc -examples -gtk (-java) -lasi -ruby -static-libs -tcl"
> > [ebuild  N     ] app-text/docbook-xml-dtd-4.5-r1
> > [ebuild  N     ] dev-libs/libxslt-1.1.26-r1  USE="crypt python -debug"
> > [ebuild  N     ] app-text/asciidoc-8.6.5  USE="-examples -highlight
> > -test -vim-syntax"
> > 
> > Is there some way we can slim this down? Presumably asciidoc isn't
> > going to be using any image-related programs for generating a man
> > page.
> 
> The image stuff is indirect dependencies, see --tree.
> 
> Future releases of catalyst do not have this problem as the make file
> comes pre-rendered with the tarball.  This is a live-ebuild issue.

No, we can't have the manpage pre-rendered in the tarball, because that
makes the tarball different every time it is created since the
date/timestamps in the archive will be different. In other words, it is
not possible for anyone to ever reproduce the exact same tarball that we
produce.

I see two ways around this: We can either make asciidoc a build time
dependency so that the user can use something like "make manpage" to
generate the manpage or we can go back to the manpage that is in the git
repository.

Thoughts?

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Sebastian Pipping]

On 06/26/2011 04:49 AM, William Hubbs wrote:
> No, we can't have the manpage pre-rendered in the tarball, because that
> makes the tarball different every time it is created since the
> date/timestamps in the archive will be different. In other words, it is
> not possible for anyone to ever reproduce the exact same tarball that we
> produce.

The varience in timestamp has been no problem for other projects
including genkernel.  If all that varies is the time stamp and it
matters to you, it would be easy to add a section to the Makefile
setting the timestamp to a hardcoded value.


> I see two ways around this: We can either make asciidoc a build time
> dependency so that the user can use something like "make manpage" to
> generate the manpage

That adds quite some load on indirect dependencies for more or less
nothing, as seen with Matt earlier.


> or we can go back to the manpage that is in the git
> repository.

Do I have to list reasons against this option?

Best,




Sebastian

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1491 bytes --]

On Sun, Jun 26, 2011 at 05:14:38AM +0200, Sebastian Pipping wrote:
> On 06/26/2011 04:49 AM, William Hubbs wrote:
> > No, we can't have the manpage pre-rendered in the tarball, because that
> > makes the tarball different every time it is created since the
> > date/timestamps in the archive will be different. In other words, it is
> > not possible for anyone to ever reproduce the exact same tarball that we
> > produce.
> 
> The varience in timestamp has been no problem for other projects
> including genkernel.  If all that varies is the time stamp and it
> matters to you, it would be easy to add a section to the Makefile
> setting the timestamp to a hardcoded value.

That is already done if you use "git archive" to generate the archive
and use the tags in the git repository along with that. For an example,
look at openrc's git repository.
> > I see two ways around this: We can either make asciidoc a build time
> > dependency so that the user can use something like "make manpage" to
> > generate the manpage
> 
> That adds quite some load on indirect dependencies for more or less
> nothing, as seen with Matt earlier.

That is exactly why I prefer the other option I mention below.

> > or we can go back to the manpage that is in the git
> > repository.
> 
> Do I have to list reasons against this option?

I think it would be helpful if you did since you did the conversion
without discussing it with the rest of the team first.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 763 bytes --]

I need to appologise for the last comment I made in my previous message
about you not discussing this issue. I see that you did mention it, but
it was before I came on board.

http://archives.gentoo.org/gentoo-catalyst/msg_78cd6eae401bfa7a499418bc6cbc225e.xml

I hope you will accept my appology.

However, I would still like to know why this conversion was needed; all
we had to do was update the manpage. The conversion does make it more
difficult for us to generate reproducable tarballs, which means that for
gentoo's qa policy someone always has to keep the tarball we use in
their dev space and we have to point to that tarball with SRC_URI.

But, that would not be necessary if we generate the tarball from the git
repo e.g. the way openrc does.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Sebastian Pipping]

On 06/26/2011 05:46 AM, William Hubbs wrote:
> I need to appologise for the last comment I made in my previous message
> about you not discussing this issue. I see that you did mention it, but
> it was before I came on board.
> 
> http://archives.gentoo.org/gentoo-catalyst/msg_78cd6eae401bfa7a499418bc6cbc225e.xml
> 
> I hope you will accept my appology.

Yes, no problem.


> However, I would still like to know why this conversion was needed;

To increase the fun maintaining it for present and future.
Run "make && man ./files/catalyst.1" to see how much better it looks now
than a few days ago.  I wouldn't have spent time on improving it at
*roff level.


> all
> we had to do was update the manpage. The conversion does make it more
> difficult for us to generate reproducable tarballs, which means that for
> gentoo's qa policy someone always has to keep the tarball we use in
> their dev space and we have to point to that tarball with SRC_URI.

I'm not following.  We have to keep the tarball on mirrors anyway.  Not?

No generated files means maintaining some things at several places.
Without the generator, mips2 and mipsel2 would still be listed on
catalyst's webpage.


> But, that would not be necessary if we generate the tarball from the git
> repo e.g. the way openrc does.

Alright.  I don't want to limit myself to a static man page (or live
with generated files under version control).

Best,



Sebastian

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Sebastian Pipping]

On 06/26/2011 05:36 AM, William Hubbs wrote:
> That is already done if you use "git archive" to generate the archive
> and use the tags in the git repository along with that. For an example,
> look at openrc's git repository.

I'm aware of git archive - it does not support handling of generated
files afaik.


>>> I see two ways around this: We can either make asciidoc a build time
>>> dependency so that the user can use something like "make manpage" to
>>> generate the manpage
>>
>> That adds quite some load on indirect dependencies for more or less
>> nothing, as seen with Matt earlier.
> 
> That is exactly why I prefer the other option I mention below.

Alright.  On the other hand without dependencies you get nowhere: either
you don#t have features or you build every wheel yourself.


>>> or we can go back to the manpage that is in the git
>>> repository.
>>
>> Do I have to list reasons against this option?
> 
> I think it would be helpful if you did since you did the conversion
> without discussing it with the rest of the team first.

Peter Volkov voted for it, Peter Stuge said the list was rather silent.
 So I went for it.  The migration in genkernel was of great help.  I see
your apology in your other mail now, accepting.

Benefits of the current Asciidoc approach:

 - No need to write *roff manually.
   Plus Asciidoc syntax is more readable.

 - Man page keeps itself in sync on

   - list of subarches

   - version of catalyst

 - Option to make XHTML from the same source

Best,



Sebastian

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2697 bytes --]

On Sun, Jun 26, 2011 at 05:49:17AM +0200, Sebastian Pipping wrote:
> On 06/26/2011 05:36 AM, William Hubbs wrote:
> > That is already done if you use "git archive" to generate the archive
> > and use the tags in the git repository along with that. For an example,
> > look at openrc's git repository.
> 
> I'm aware of git archive - it does not support handling of generated
> files afaik.

That's correct, everything has to be in the repository if you use it.
The advantage of doing it that way is that anyone can come along
whenever they want to and generate a tarball that exactly matches the
one we generate at release time. Doing it the other way, they can't.
 
 That is why I think we should make asciidoc an RDEPEND in the ebuilds
 and set up the makefile so that the user generates the content if we
 stick with using asciidoc.

> >>> I see two ways around this: We can either make asciidoc a build time
> >>> dependency so that the user can use something like "make manpage" to
> >>> generate the manpage
> >>
> >> That adds quite some load on indirect dependencies for more or less
> >> nothing, as seen with Matt earlier.
> > 
> > That is exactly why I prefer the other option I mention below.
> 
> Alright.  On the other hand without dependencies you get nowhere: either
> you don#t have features or you build every wheel yourself.
 
 I'm not quite sure what you mean here.

> >>> or we can go back to the manpage that is in the git
> >>> repository.
> >>
> >> Do I have to list reasons against this option?
> > 
> > I think it would be helpful if you did since you did the conversion
> > without discussing it with the rest of the team first.
> 
> Peter Volkov voted for it, Peter Stuge said the list was rather silent.
>  So I went for it.  The migration in genkernel was of great help.  I see
> your apology in your other mail now, accepting.
> 
> Benefits of the current Asciidoc approach:
> 
>  - No need to write *roff manually.

I'll give you this one. :-)

>    Plus Asciidoc syntax is more readable.

You can use man ./catalyst.1 to read the man page.

> 
>  - Man page keeps itself in sync on
> 
>    - list of subarches
> 
>    - version of catalyst
> 
>  - Option to make XHTML from the same source
 
 The cons of the new approach, as I see it, are:

* auto generated content in tarballs makes it impossible to create the
exact same tarball twice.
* Now we need to have a build time dependency, at least for the live
ebuild, which pulls in about 34mb of downloads just to build the man
page.

Since we are just talking about a man page, imho this is a lot of bloat
for very little gain.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Sebastian Pipping]

On 06/26/2011 06:33 AM, William Hubbs wrote:
> That's correct, everything has to be in the repository if you use it.
> The advantage of doing it that way is that anyone can come along
> whenever they want to and generate a tarball that exactly matches the
> one we generate at release time. Doing it the other way, they can't.

Frankly, I don't care about that feature.  I care about content and Git
tags that lead to content.


>> Alright.  On the other hand without dependencies you get nowhere: either
>> you don#t have features or you build every wheel yourself.
>  
>  I'm not quite sure what you mean here.

I was trying to say that you get quite something for the cost you put
into dependencies.  You save re-writing things yourself and you get more
features for free.  That's what the cost is for.


>>    Plus Asciidoc syntax is more readable.
> 
> You can use man ./catalyst.1 to read the man page.

Are you serious?  I want syntax to be readable while editing, not after
pre-processing.  With that argument we could be writing man pages in
assembly.

> 
>>
>>  - Man page keeps itself in sync on
>>
>>    - list of subarches
>>
>>    - version of catalyst
>>
>>  - Option to make XHTML from the same source
>  
>  The cons of the new approach, as I see it, are:
> 
> * auto generated content in tarballs makes it impossible to create the
> exact same tarball twice.

Again, i don't care.


> * Now we need to have a build time dependency, at least for the live
> ebuild, which pulls in about 34mb of downloads just to build the man
> page.
> 
> Since we are just talking about a man page, imho this is a lot of bloat
> for very little gain.

I disagree on bloat and on little gain.

If you insist on changing status quo I would like to call in a vote.

Best,



Sebastian

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Matt Turner]

On Sun, Jun 26, 2011 at 12:57 AM, Sebastian Pipping <sping@gentoo.org> wrote:
>> * Now we need to have a build time dependency, at least for the live
>> ebuild, which pulls in about 34mb of downloads just to build the man
>> page.
>>
>> Since we are just talking about a man page, imho this is a lot of bloat
>> for very little gain.
>
> I disagree on bloat and on little gain.
>
> If you insist on changing status quo I would like to call in a vote.

Well, in fairness, the asciidoc dependency was just added a day or so ago.

But, I really don't think it's as big a problem as this long email
thread warrants. We simply want to avoid asciidoc, and specifically
it's dependencies, for catalyst snapshots. For the live ebuild, I
don't see the dependencies as a problem.

Can't we simply get the timestamp of the last commit to the git
branch/tag that we're making an archive from and apply it to the
generated content? Doing this would allow us to reproduce an identical
tarball, and avoids a lot of other problems discussed in this thread.

Thanks,
Matt

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]

On Sun, Jun 26, 2011 at 11:44:55AM -0400, Matt Turner wrote:
> On Sun, Jun 26, 2011 at 12:57 AM, Sebastian Pipping <sping@gentoo.org> wrote:
> >> * Now we need to have a build time dependency, at least for the live
> >> ebuild, which pulls in about 34mb of downloads just to build the man
> >> page.
> >>
> >> Since we are just talking about a man page, imho this is a lot of bloat
> >> for very little gain.
> >
> > I disagree on bloat and on little gain.
> >
> > If you insist on changing status quo I would like to call in a vote.
> 
> Well, in fairness, the asciidoc dependency was just added a day or so ago.

Yes, it was added a couple of days ago, without giving a reasonable
amount of time for discussion.

I'll post the links to the rfc [1], the approval message [2] and the
message where the change was checked in [3] below. Notice that this all
happened within a period less than 24 hours.

For a significant change like this, I
think we should give 24-48 hours and make the patch visible somewhere so
that others can look at the change and comment on it before it gets
checked in. Remember that we have people here in multiple time zones,
and we don't necessarily check these lists every day.

Based on this as well as my previous objections I would like to see this
change reverted.

William

[1] http://archives.gentoo.org/gentoo-catalyst/msg_78cd6eae401bfa7a499418bc6cbc225e.xml
[2] http://archives.gentoo.org/gentoo-catalyst/msg_65f2fce710454e481973d0e2c6cc5265.xml
[3] http://archives.gentoo.org/gentoo-catalyst/msg_f2eb026c4c4af90650952ca81a5fd6b6.xml

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Peter Stuge]

[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]

William Hubbs wrote:
> Yes, it was added a couple of days ago, without giving a reasonable
> amount of time for discussion.

You know just as well as I do that this thread is the most discussion
that this mailing list has seen in a very long time. Sebastian wants
to make some progress. I see no problem.


> For a significant change like this,

"significant" is so subjective though.


> I think we should give 24-48 hours and make the patch visible
> somewhere

It is clear that you are displeased because you think you did not
have a chance to oppose the change before it was made. I can
understand, but in reality I doubt the one opposing voice would
have made a difference.


> Remember that we have people here in multiple time zones,

This is a given for all project. Not sure why you think anyone needs
to be reminded of this.


> and we don't necessarily check these lists every day.

I would set some kind of notification up, so that response does not
depend on me checking something.


> Based on this as well as my previous objections I would like to see
> this change reverted.

I disagree and hope that most others do as well, so that development
will continue instead of being stuck on senseless arguing with you.

What about my suggestion to fix the actual problem, asciidoc
dependencies, did you bother looking into that yet? (I haven't
because I don't feel at all strongly.)

Thanks!


//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Matt Turner]

On Sun, Jun 26, 2011 at 1:55 PM, Peter Stuge <peter@stuge.se> wrote:
> What about my suggestion to fix the actual problem, asciidoc
> dependencies, did you bother looking into that yet? (I haven't
> because I don't feel at all strongly.)

I asked wired on #gentoo-dev but haven't received a response yet.

I've looked at the source, and it's not clear to me that it's possible.

Matt

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Peter Stuge]

Matt Turner wrote:
> > What about my suggestion to fix the actual problem, asciidoc
> > dependencies,
> 
> I've looked at the source, and it's not clear to me that it's possible.

Someone feeling strongly would add the possibility upstream.


//Peter

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Matt Turner]

On Sun, Jun 26, 2011 at 2:02 PM, Matt Turner <mattst88@gentoo.org> wrote:
> On Sun, Jun 26, 2011 at 1:55 PM, Peter Stuge <peter@stuge.se> wrote:
>> What about my suggestion to fix the actual problem, asciidoc
>> dependencies, did you bother looking into that yet? (I haven't
>> because I don't feel at all strongly.)
>
> I asked wired on #gentoo-dev but haven't received a response yet.
>
> I've looked at the source, and it's not clear to me that it's possible.
>
> Matt

A user in #gentoo-releng pointed me to https://bugs.gentoo.org/361255

It looks like asciidoc can be installed and used to generate man pages
without graphviz.

So with that fixed, unless someone has an issue with asciidoc being a
dependency for catalyst, crisis averted! :)

Matt

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 26-06-2011 17:55, Peter Stuge wrote:
> William Hubbs wrote:
>> Yes, it was added a couple of days ago, without giving a reasonable
>> amount of time for discussion.
> 
> You know just as well as I do that this thread is the most discussion
> that this mailing list has seen in a very long time. Sebastian wants
> to make some progress. I see no problem.

Yes and I'm happy to see people interested on catalyst.
However, given the recent discussions I feel I should point out that
catalyst is Release Engineering's team release tool and not a "toy" for
people to tinker with.
I appreciate the interest all of you are showing for the tool and I
appreciate any improvements, but I and other releng team members need
this tool to work for us to have releases.

>> For a significant change like this,
> 
> "significant" is so subjective though.

It did made a significant change to the dependencies of catalyst.
I haven't checked it closely yet, but I also wonder if all the
additional deps are worth avoiding a single man page in the tarball.

>> I think we should give 24-48 hours and make the patch visible
>> somewhere
> 
> It is clear that you are displeased because you think you did not
> have a chance to oppose the change before it was made. I can
> understand, but in reality I doubt the one opposing voice would
> have made a difference.

William is not the only one to have concerns about this change.
Also, prior to the subscription by agaffney, armin76 and myself, this
list probably had little if any releng members. As this is a releng
tool, not having us around to "object" doesn't make it ok to commit
changes without ensuring releng is ok with the changes.

>> Based on this as well as my previous objections I would like to see
>> this change reverted.
> 
> I disagree and hope that most others do as well, so that development
> will continue instead of being stuck on senseless arguing with you.

I'm sorry but this is not about arguing with William. This is about
making sure that the people interested as well as the direct consumers
of the tool are ok with any proposed changes.
I'm sure no one wants to risk causing a split that could lead to either
releng assuming control of catalyst again or worse causing a fork in the
code.

> What about my suggestion to fix the actual problem, asciidoc
> dependencies, did you bother looking into that yet? (I haven't
> because I don't feel at all strongly.)
> 
> Thanks!
> 
> 
> //Peter

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJOB8AxAAoJEC8ZTXQF1qEPyeAP/iQ26OaLYHOaE8SirGp1nsiP
ET6RKcO60a25SeiicIgM6jcJ0HX6u71G6DEPR9jI4dk6yxQoNCxsfvLimIURqhHU
GAwdowhaa0dRQtaQejLYFo30t2TrzhqPsFu+oILskeLifOqoQDWvHG2IeBvQ04Vl
dB8rA6GKu4EKbY/i0XreFO8rjOgW2rjTY8PB+hDagGUK0mqqle1VlHJmW/w5pNwD
NhyyGIwHY7M6sf+HI6QgGr6nzUYeAxMbBtozu/kTNtqp09fkjtis35cKMPYExyCF
8w9mTgLsqa151nIcDP7+IhWkJKPnaxS7EHg2mApnZH4JRNEHd39CJLPVk2Gg3FQg
2lp5K4N4JjePC1Ejd5ciL5Po/R7wAsFT2rLwk35xSTM/nhv6lAOjc/Qq2xEA5IUg
5uU6crwthJOMj07kqiT+YuT6mOK3NnNObkpLnyx7aAQAjTe8LfUWEtVSSgJ40wM2
xTLAE1uDVK7lI/PD4pL+DtFjej263RSRha5PRmYDg24yMTZoV2ZExc4vzbqfrysp
TjNc7kdWtZrzr4a4snGkzpKhD2gI9ivjorfsQr32QXaiSK/+1uLkF9sQIyy2YOvl
qsZiu7hImn39hzJRWbnjv9cxnT/zVs5Q0K32W4FJyqBP3YLmFPtE4UdES1wxDhuH
kV6bW26ZyWLnt/txLQYY
=crYh
-----END PGP SIGNATURE-----

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Peter Stuge]

Jorge Manuel B. S. Vicetto wrote:
> I feel I should point out that catalyst is Release Engineering's
> team release tool and not a "toy" for people to tinker with.

Toy? Saying that other people's use of catalyst is only play, while
releng is the only serious user, is really spitting in the face of
everyone who uses catalyst. Maybe not so helpful.

Meeting you I think you seemed sensible enough that you of course
understand that catalyst is equally much a tool for all it's users.


> I appreciate the interest all of you are showing for the tool and I
> appreciate any improvements, but I and other releng team members need
> this tool to work for us to have releases.

No problem. Like every other consumer of open source tools you simply
need to pick the version you choose to use carefully, so that it
works for you. This case is not different from any other tool issue.


> >> For a significant change like this,
> > 
> > "significant" is so subjective though.
> 
> It did made a significant change to the dependencies of catalyst.

No, not really. It added one dependency, which is hardly significant.
As has already been shown (by others than William, might I add)
further indirect dependencies are really a bug in the asciidoc
ebuild, and should be fixed there. Since you are all developers
(while I am not) you could actually *already* have eliminated the
point of contention - but noone has bothered and instead you're
writing email complaining about how a little bit of progress is
ruining your workflow. (This is how it looks anyway.)


> I haven't checked it closely yet,

Maybe that's actually wise, to determine how significant the change
is?


> William is not the only one to have concerns about this change.

He was so far the only one who voice any, and they weren't so nicely
expressed.


> this list probably had little if any releng members. As this is a
> releng tool,

Either "your" catalyst is an open source project or it is not. If it
is not then you need to hide it away in a secret internal repo so
that noone else in the world can access it. Or you can just do what
the rest of the world does; verify your tools before expecting them
to work.

I understand that you want stable tools, but if you want frozen tools
then you need to do that on your own - because other catalyst users
can and will want to change things. Absolutely not very often, but
apparently often enough that it's a problem for releng to continue
be part of the catalyst community. Or?


> not having us around to "object" doesn't make it ok to commit
> changes without ensuring releng is ok with the changes.

If so, that in itself is reason for forking, as was discussed.

I would have zero bad feelings about that, because the wants and
needs simply seem to be different between releng and all other
catalyst users.


> This is about making sure that the people interested as well as the
> direct consumers of the tool are ok with any proposed changes.

You are neglecting every other user than releng. That means me. That
sucks.


> I'm sure no one wants to risk causing a split that could lead to either
> releng assuming control of catalyst again or worse causing a fork in the
> code.

Actually, forking is indeed the one and only productive step when
different users have different enough requirements and expectations.


//Peter

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 27-06-2011 00:00, Peter Stuge wrote:
> Jorge Manuel B. S. Vicetto wrote:
>> I feel I should point out that catalyst is Release Engineering's
>> team release tool and not a "toy" for people to tinker with.
> 
> Toy? Saying that other people's use of catalyst is only play, while
> releng is the only serious user, is really spitting in the face of
> everyone who uses catalyst. Maybe not so helpful.
> 
> Meeting you I think you seemed sensible enough that you of course
> understand that catalyst is equally much a tool for all it's users.

Peter,

I didn't mean to imply that anyone else uses catalyst as a toy. What I
was saying is that catalyst is a "crucial" tool to releng, whilst to
some of the people currently working on it (having commit privileges to
the repo) it could be a "toy".
I did not and do not in any way want to diminish the importance of the
tool to any of its users. At the same time, it should be obvious that
releng is a "special" user of the tool.

>> I appreciate the interest all of you are showing for the tool and I
>> appreciate any improvements, but I and other releng team members need
>> this tool to work for us to have releases.
> 
> No problem. Like every other consumer of open source tools you simply
> need to pick the version you choose to use carefully, so that it
> works for you. This case is not different from any other tool issue.
> 
>>>> For a significant change like this,
>>>
>>> "significant" is so subjective though.
>>
>> It did made a significant change to the dependencies of catalyst.
> 
> No, not really. It added one dependency, which is hardly significant.
> As has already been shown (by others than William, might I add)
> further indirect dependencies are really a bug in the asciidoc
> ebuild, and should be fixed there. Since you are all developers
> (while I am not) you could actually *already* have eliminated the
> point of contention - but noone has bothered and instead you're
> writing email complaining about how a little bit of progress is
> ruining your workflow. (This is how it looks anyway.)

As you know the current dependency pulls more than 10 deps. I don't know
if they're accurate or not, but they show up when you try to merge
catalyst-9999. If those deps are wrong, we should try to get the team
maintaining the asciidoc package fix them.

>> I haven't checked it closely yet,
> 
> Maybe that's actually wise, to determine how significant the change
> is?
> 
> 
>> William is not the only one to have concerns about this change.
> 
> He was so far the only one who voice any, and they weren't so nicely
> expressed.

He wasn't happy to see something pushed through in a so short time span
and in a way that seemed to go over others opinions. I also wasn't happy.

>> this list probably had little if any releng members. As this is a
>> releng tool,
> 
> Either "your" catalyst is an open source project or it is not. If it
> is not then you need to hide it away in a secret internal repo so
> that noone else in the world can access it. Or you can just do what
> the rest of the world does; verify your tools before expecting them
> to work.

It is an open source project and we want it to be - no argument about
that. The commit privileges were restricted to releng or some of its
members until a short time ago.
As with other open source projects, releng is happy to see the tool
improve and is open for new features and requests from the users.
However, like any other open source project, there needs to be some
consensus.

> I understand that you want stable tools, but if you want frozen tools
> then you need to do that on your own - because other catalyst users
> can and will want to change things. Absolutely not very often, but
> apparently often enough that it's a problem for releng to continue
> be part of the catalyst community. Or?

We're not interested in frozen tools, but we're also not ready to be
kept in the sidelines or ignored about catalyst development. Some of the
people now working on them are not building or responsible for the
building of the official releases, I and a few others are.
I have no interest in having catalyst forked, but for that, the
developers that got access to catalyst need to realize they need to work
with releng and can't ignore it.

>> not having us around to "object" doesn't make it ok to commit
>> changes without ensuring releng is ok with the changes.
> 
> If so, that in itself is reason for forking, as was discussed.
> 
> I would have zero bad feelings about that, because the wants and
> needs simply seem to be different between releng and all other
> catalyst users.

Sometimes forks can be the best solution, but I really would like to
avoid that. I don't see why we shouldn't talk to ensure we reach
consensus that work for anyone. At times, a consensus might not be
possible, but in those cases the decision will hopefully not cause
enough problems or grief as to send people away. If we end up having to
make decisions that split the user base of the tool, then people can
think about doing a fork.
So, I think a fork should be the last option and that we should work
hard to reach decisions that everyone can live with.

>> This is about making sure that the people interested as well as the
>> direct consumers of the tool are ok with any proposed changes.
> 
> You are neglecting every other user than releng. That means me. That
> sucks.

That is not my purpose. Furthermore, as I've tried to explain above, my
previous mail was not about the users of the tool but about the recent
people committing to the repo.

>> I'm sure no one wants to risk causing a split that could lead to either
>> releng assuming control of catalyst again or worse causing a fork in the
>> code.
> 
> Actually, forking is indeed the one and only productive step when
> different users have different enough requirements and expectations.
> 
> 
> //Peter
> 

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJOB89zAAoJEC8ZTXQF1qEPA0IQAJssiqfYbS8bE9w3hjpSS3jn
HpnUWIoLTkst3VSYO/jGr37mthbx7YbxtXm6V4EL0D4hhNSWfKUybTriTTl29yCY
vbDqDrrb8JcJMTx2UAg7q8BjsPpxIo2xhcjQoVX4O1m9zvWeVKgXJIGW/sJ9UKyl
ZhcgMGmXGQskraKmTHHxk6aOWgE7iQxmMMZooVm0IYY8TphesMnqncxJveleOPHx
0kSTOqsm3QedjHq5MAJcLkPF3cFqJ5f3xfQ7tFWqDBTxDABaHp9Q7FF6J4jCa8p/
DyLW7gYK7NHUXYaemjntumgR/8/l4nGUm4OB+X6nMtSy40jQPBZEghMtu1/Kuy5r
9ss82MWh8sn7rW4FusF05JxpSe/du6kh8lrVkCVvJWRnTslWjsmFLOW3RoTnymHI
MZr/d+foLNdc9uxOcDiBbjYH0rdOPsqnoygCgMvyOOwKmnqDjnt567vrNh7iRUC/
f/rl5SfEi7cUWHU8OP2GgDsleC22BaNKC8Sb7hvEp4qWiQziBjKaDv/plFEwGWGq
6qfbJ4+B3oX4TmCm/Rc2LesByyyk8kyNIVYA3wBRAvajn9qeJ9+Ki/Ezo7Aqcvkm
9uzLIxEppegt8NqJzZLmjlCI6gplvRxHfsl10JH/fMZj8tyyP4r8zX/A56fq7763
ou2cZRzmYmLFp8haqTT2
=vgjW
-----END PGP SIGNATURE-----

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Peter Stuge]

Jorge Manuel B. S. Vicetto wrote:
> I didn't mean to imply that anyone else uses catalyst as a toy. What I
> was saying is that catalyst is a "crucial" tool to releng, whilst to
> some of the people currently working on it (having commit privileges to
> the repo) it could be a "toy".

I'm pretty sure Sebastian is not spending time on catalyst because it
makes him laugh. :)


> I did not and do not in any way want to diminish the importance of the
> tool to any of its users. At the same time, it should be obvious that
> releng is a "special" user of the tool.

I'm not so sure I buy that. But we can punt on that.


> >> It did made a significant change to the dependencies of catalyst.
> > 
> > No, not really. It added one dependency, which is hardly significant.
> > As has already been shown (by others than William, might I add)
> > further indirect dependencies are really a bug in the asciidoc
> > ebuild, and should be fixed there.
..
> As you know the current dependency pulls more than 10 deps. I don't
> know if they're accurate or not, but they show up when you try to
> merge catalyst-9999.

And those who really dislike them can look into getting rid of them.


> If those deps are wrong, we should try to get the team maintaining
> the asciidoc package fix them.

Yeah, to silence this silly discussion I tried to do exactly that.
But see my point above:

> > Since you are all developers (while I am not) you could actually
> > *already* have eliminated the point of contention

Again, I believe the problem is solved by the attachments I made to
#361255.

(Note that the oldest version in portage, 8.2.6, correctly does not
have the dep.)


> He wasn't happy to see something pushed through in a so short time span
> and in a way that seemed to go over others opinions. I also wasn't happy.

Yes, how will we all cope with a six year old man page being updated. :p


> like any other open source project, there needs to be some consensus.

This is fair. But the fact that others only recently have gotten
commit access is likely just coincidence. I'm at least quite
convinced that it has nothing to do with why Sebastian started
looking at the tool.


> We're not interested in frozen tools, but we're also not ready to
> be kept in the sidelines or ignored about catalyst development.

Cool. More activity in the catalyst community can only be good!


> Some of the people now working on them are not building or
> responsible for the building of the official releases, I and a few
> others are.

Again, I'm not so sure that this matters very much. If an older
version worked for you then maybe that's what you should keep using
until latest git has also been verified to work for you? Dunno, this
is trickier, and indeed something important (for you) to figure out,
when you choose to open source "your" tool. (Which I think is a good
move!)


> I have no interest in having catalyst forked, but for that, the
> developers that got access to catalyst need to realize they need
> to work with releng and can't ignore it.

I guess you've read the full thread and also know how little activity
there has been on the list. Since there was very close to zero
activity here over many months I think it's safe to assume that any
ignoring was not really in spite, but rather a side effect of
ignorees being too slow to keep up with the momentum.


> Sometimes forks can be the best solution, but I really would like
> to avoid that.

Well, even if there is a fork that doesn't mean that changes can not
flow both ways. Again, if one user of a tool has special needs it's
not at all a bad idea to have a fork.


> So, I think a fork should be the last option and that we should work
> hard to reach decisions that everyone can live with.

It took me all of an hour to (continue) research *and fix* the
problem in the asciidoc ebuilds. That's probably less than people
have spent on emails in this thread. :)


> >> This is about making sure that the people interested as well as the
> >> direct consumers of the tool are ok with any proposed changes.
> > 
> > You are neglecting every other user than releng. That means me. That
> > sucks.
> 
> That is not my purpose. Furthermore, as I've tried to explain above, my
> previous mail was not about the users of the tool but about the recent
> people committing to the repo.

I'm also quite convinced that Sebastien wouldn't be spending time on
catalyst unless he was using it. :) (In fact, maybe even because I've
told him about how I use it!)


//Peter

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Sebastian Pipping]

On 06/27/2011 02:31 AM, Jorge Manuel B. S. Vicetto wrote:
> [..] when you try to merge catalyst-9999.

While you mention 9999: are you using 9999 for private stuff or for the
real releng releases?  If it's releng why choose 9999 over 2.0.6.916?
(If you told me on IRC I forgot.)

At least the ebuilds still say that 3.x is not supported and that even
bug reports should not be taken to bugzilla, directly.
Maybe that's an indicator that master should be merged (one way or
another) into catalyst_2 code, not the other way around.

Best,



Sebastian

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 27-06-2011 01:43, Sebastian Pipping wrote:
> On 06/27/2011 02:31 AM, Jorge Manuel B. S. Vicetto wrote:
>> [..] when you try to merge catalyst-9999.
> 
> While you mention 9999: are you using 9999 for private stuff or for the
> real releng releases?  If it's releng why choose 9999 over 2.0.6.916?
> (If you told me on IRC I forgot.)

We use 2.0.6.916 on official releng releases.
I tried 9999 on my private tests because I wanted to try
likewhoa/WilliamH patch to have the installcd boot the hard disk is the
user doesn't press a key.

> At least the ebuilds still say that 3.x is not supported and that even
> bug reports should not be taken to bugzilla, directly.
> Maybe that's an indicator that master should be merged (one way or
> another) into catalyst_2 code, not the other way around.

I can confirm that the build with the master branch fails as it doesn't
seem able to find the spec files or doesn't accept them - the official
ones we use to build weekly releases.

> Best,
> 
> 
> Sebastian

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJOB//LAAoJEC8ZTXQF1qEPFUIP/jkASxlANKZ/tOPmBXmE+9YG
yjk6Lowas6fVJA5bs2PTXw09+8y4Pcnjxr0dO1rMNX9Fzse3jqk85zO4KGW1135u
Y8GT8hswpAW8pjoTdvfnVTJUDgw4r8FncI/kdE0NhLETHA/ITwZGg8KOeReBhU2g
QyTAXYF6Bo5MMipwl1q6qKpEUzmSqz4sbj/GazHIX31JukORz97cSsj99zJRiwhE
pikC7xrO/k56hoHGNELMXp7XUgOiDGsQOYpgQB6dRBs2Qz2gxsB/EfZELXg6pTG4
i5J0LMrxrHtDt2TnBF1MRCZ3N6KOsam5/y1QVxkdV/5W4EWMxJctBucQWpLaqJfD
1UXcXWg/q04arGWoLviKedJGfIiMClEWd0fDmH5Evp6HpnLX/Lpdp31cxbruLWD7
TOTrzmLaQ8mNep5ZFP8MacSE+uO7HqcCC5796NknjAZbQqDFbbSLK0i9ZiaDLSkk
TPFmJDZzzg+5/L8UpWiK1cyEDfaicbes/TITeB40I1c/+CQtDKghlvujozNUhft/
mIoAF5iTaZeo3wRsVQGxPTfassvZwG8TmITqcnFzabUvWeOzgem9TyPrQOWErf/w
TuYtdLKHvtzrN59g0unp4KQ7D3BBqxzTUFWppTYAOY7o9rSpjlnOQF9xquMNFeCe
xvwUqPqDmPw9IDrQpU3X
=4cc7
-----END PGP SIGNATURE-----

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Sebastian Pipping]

On 06/27/2011 05:58 AM, Jorge Manuel B. S. Vicetto wrote:
> We use 2.0.6.916 on official releng releases.
> I tried 9999 on my private tests because [..]

To me that leaves the question who uses 9999 for serious stuff at all.
In case it's no one (which we should find out) we could trash that
branch and fully concentrate on calalyst_2.

I guess that sounds a bit radical at first.  It doesn't have to be a
quick decision.  Also, version control allows us to bring it back if needed.

Ideas on find out who is using 9999:

 - Removing 9999 ebuild from the tree and see who's complaining

 - Resetting branch master to nothing but a README announcing
   the possible death of that thread and a request to join
   this mailing list and speak up about it if there is need.

 - Asking on one/some/all of gentoo-dev, gentoo-user, gentoo forums,
   planet gentoo.

After such action I imagine a time window of 2 to 4 weeks to give people
a chance to react.

What do you think?


> I can confirm that the build with the master branch fails as it doesn't
> seem able to find the spec files or doesn't accept them - the official
> ones we use to build weekly releases.

That seems to further decrease the chance that someone is using 9999 for
real to me.

Best,




Sebastian

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Sebastian Pipping]

On 06/27/2011 05:55 PM, Sebastian Pipping wrote:
> On 06/27/2011 05:58 AM, Jorge Manuel B. S. Vicetto wrote:
>> We use 2.0.6.916 on official releng releases.
>> I tried 9999 on my private tests because [..]
> 
> To me that leaves the question who uses 9999 for serious stuff at all.
> In case it's no one (which we should find out) we could trash that
> branch and fully concentrate on calalyst_2.
> 
> I guess that sounds a bit radical at first.  It doesn't have to be a
> quick decision.  Also, version control allows us to bring it back if needed.
> 
> Ideas on find out who is using 9999:
> 
>  - Removing 9999 ebuild from the tree and see who's complaining
> 
>  - Resetting branch master to nothing but a README announcing
>    the possible death of that thread and a request to join
>    this mailing list and speak up about it if there is need.
> 
>  - Asking on one/some/all of gentoo-dev, gentoo-user, gentoo forums,
>    planet gentoo.
> 
> After such action I imagine a time window of 2 to 4 weeks to give people
> a chance to react.
> 
> What do you think?
> 
> 
>> I can confirm that the build with the master branch fails as it doesn't
>> seem able to find the spec files or doesn't accept them - the official
>> ones we use to build weekly releases.
> 
> That seems to further decrease the chance that someone is using 9999 for
> real to me.

One week has passed by.  Anyone?



Sebastian

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Matt Turner]

On Sun, Jul 3, 2011 at 11:28 PM, Sebastian Pipping <sping@gentoo.org> wrote:
> On 06/27/2011 05:55 PM, Sebastian Pipping wrote:
>> On 06/27/2011 05:58 AM, Jorge Manuel B. S. Vicetto wrote:
>>> We use 2.0.6.916 on official releng releases.
>>> I tried 9999 on my private tests because [..]
>>
>> To me that leaves the question who uses 9999 for serious stuff at all.
>> In case it's no one (which we should find out) we could trash that
>> branch and fully concentrate on calalyst_2.
>>
>> I guess that sounds a bit radical at first.  It doesn't have to be a
>> quick decision.  Also, version control allows us to bring it back if needed.
>>
>> Ideas on find out who is using 9999:
>>
>>  - Removing 9999 ebuild from the tree and see who's complaining
>>
>>  - Resetting branch master to nothing but a README announcing
>>    the possible death of that thread and a request to join
>>    this mailing list and speak up about it if there is need.
>>
>>  - Asking on one/some/all of gentoo-dev, gentoo-user, gentoo forums,
>>    planet gentoo.
>>
>> After such action I imagine a time window of 2 to 4 weeks to give people
>> a chance to react.
>>
>> What do you think?
>>
>>
>>> I can confirm that the build with the master branch fails as it doesn't
>>> seem able to find the spec files or doesn't accept them - the official
>>> ones we use to build weekly releases.
>>
>> That seems to further decrease the chance that someone is using 9999 for
>> real to me.
>
> One week has passed by.  Anyone?

I'm perfectly fine with the change, especially after the graphviz
dependency of asciidoc was made optional.

Matt

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Sebastian Pipping]

On 07/04/2011 02:10 AM, Matt Turner wrote:
>>>> We use 2.0.6.916 on official releng releases.
>>>> I tried 9999 on my private tests because [..]
>>>
>>> To me that leaves the question who uses 9999 for serious stuff at all.
>>> In case it's no one (which we should find out) we could trash that
>>> branch and fully concentrate on calalyst_2.
>>>
>>> I guess that sounds a bit radical at first.  It doesn't have to be a
>>> quick decision.  Also, version control allows us to bring it back if needed.
>>>
>>> Ideas on find out who is using 9999:
>>>
>>>  - Removing 9999 ebuild from the tree and see who's complaining
>>>
>>>  - Resetting branch master to nothing but a README announcing
>>>    the possible death of that thread and a request to join
>>>    this mailing list and speak up about it if there is need.
>>>
>>>  - Asking on one/some/all of gentoo-dev, gentoo-user, gentoo forums,
>>>    planet gentoo.
>>>
>>> After such action I imagine a time window of 2 to 4 weeks to give people
>>> a chance to react.
>>>
>>> What do you think?
>>>
>>>
>>>> I can confirm that the build with the master branch fails as it doesn't
>>>> seem able to find the spec files or doesn't accept them - the official
>>>> ones we use to build weekly releases.
>>>
>>> That seems to further decrease the chance that someone is using 9999 for
>>> real to me.
>>
>> One week has passed by.  Anyone?
> 
> I'm perfectly fine with the change, especially after the graphviz
> dependency of asciidoc was made optional.

Please re-read the text above.  It's not about asciidoc.
I'll make a new thread.

Best,



Sebastian

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Peter Stuge]

Peter Stuge wrote:
> As has already been shown (by others than William, might I add)
> further indirect dependencies are really a bug in the asciidoc
> ebuild, and should be fixed there.

I just attached live ebuild patch and -r1 ebuilds for all existing
versions which had a graphviz dependency (8.2.6 already did not) at:

https://bugs.gentoo.org/show_bug.cgi?id=361255


> Since you are all developers (while I am not) you could actually
> *already* have eliminated the point of contention

Please review and commit if agreeable. It probably took me all of one
hour to do, following Matt's research.


Thanks!

//Peter

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Matt Turner]

On Sun, Jun 26, 2011 at 1:33 PM, William Hubbs <williamh@gentoo.org> wrote:
> On Sun, Jun 26, 2011 at 11:44:55AM -0400, Matt Turner wrote:
>> On Sun, Jun 26, 2011 at 12:57 AM, Sebastian Pipping <sping@gentoo.org> wrote:
>> >> * Now we need to have a build time dependency, at least for the live
>> >> ebuild, which pulls in about 34mb of downloads just to build the man
>> >> page.
>> >>
>> >> Since we are just talking about a man page, imho this is a lot of bloat
>> >> for very little gain.
>> >
>> > I disagree on bloat and on little gain.
>> >
>> > If you insist on changing status quo I would like to call in a vote.
>>
>> Well, in fairness, the asciidoc dependency was just added a day or so ago.
>
> Yes, it was added a couple of days ago, without giving a reasonable
> amount of time for discussion.

He got a single response from a Gentoo developer which is infinitely
more discussion than a large number of posts on this list receive.

Even there, the post said

> For me if man page was not touched since 2005 means that it's completely
> unmaintained and thus since you are interested in maintaining - just go
> ahead!

This really is applicable to catalyst too. It'd been almost entirely
unmaintained, less trivial changes, for quite sometime.

> I'll post the links to the rfc [1], the approval message [2] and the
> message where the change was checked in [3] below. Notice that this all
> happened within a period less than 24 hours.
>
> For a significant change like this, I
> think we should give 24-48 hours and make the patch visible somewhere so
> that others can look at the change and comment on it before it gets
> checked in. Remember that we have people here in multiple time zones,
> and we don't necessarily check these lists every day.
>
> Based on this as well as my previous objections I would like to see this
> change reverted.
>
> William
>
> [1] http://archives.gentoo.org/gentoo-catalyst/msg_78cd6eae401bfa7a499418bc6cbc225e.xml
> [2] http://archives.gentoo.org/gentoo-catalyst/msg_65f2fce710454e481973d0e2c6cc5265.xml
> [3] http://archives.gentoo.org/gentoo-catalyst/msg_f2eb026c4c4af90650952ca81a5fd6b6.xml

Let's not go down this route. This seems like much ado about nothing.

I claim that
(1) app-text/asciidoc and its dependencies are not unreasonable for
catalyst-9999
(2) app-text/asciidoc and its dependencies should be avoided for
catalyst snapshots/releases
(3) we can simply modify the timestamp of the generated files to be
that of the most recent commit that `git archive` has access to,
thereby allowing us to reproduce identical tarballs
(4) checking in generated content into git is dirty. We should not do this

Do you disagree with any of these points, and if so, which?

Matt

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Sebastian Pipping]

On 06/26/2011 07:55 PM, Matt Turner wrote:
> I claim that
> (1) app-text/asciidoc and its dependencies are not unreasonable for
> catalyst-9999
> (2) app-text/asciidoc and its dependencies should be avoided for
> catalyst snapshots/releases
> (3) we can simply modify the timestamp of the generated files to be
> that of the most recent commit that `git archive` has access to,
> thereby allowing us to reproduce identical tarballs

I played with this in the Makefile now.  The only easy solution that
really gives stable checksums is setting time including modification
time to the time of the related commit.  So that means loss of real
modification times.  If you want to go that route the command

  touch --date=$(git log --pretty=%ci -1) foo

could be handy.  I guess git archive looks at timestamps from the git
store only to avoid that.  Using git archive and pulling generated files
in after may work, but it#s more research than I would like to do myself.


> (4) checking in generated content into git is dirty. We should not do this
> 
> Do you disagree with any of these points, and if so, which?
> 
> Matt
> 

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 719 bytes --]

On Sun, Jun 26, 2011 at 08:17:25PM +0200, Sebastian Pipping wrote:
> I played with this in the Makefile now.  The only easy solution that
> really gives stable checksums is setting time including modification
> time to the time of the related commit.  So that means loss of real
> modification times.  If you want to go that route the command
> 
>   touch --date=$(git log --pretty=%ci -1) foo
> 
> could be handy.  I guess git archive looks at timestamps from the git
> store only to avoid that.  Using git archive and pulling generated files
> in after may work, but it#s more research than I would like to do myself.

I'll take a look at this and  post a patch if I come up with something.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Matt Turner]

On Sat, Jun 25, 2011 at 11:14 PM, Sebastian Pipping <sping@gentoo.org> wrote:
> On 06/26/2011 04:49 AM, William Hubbs wrote:
>> No, we can't have the manpage pre-rendered in the tarball, because that
>> makes the tarball different every time it is created since the
>> date/timestamps in the archive will be different. In other words, it is
>> not possible for anyone to ever reproduce the exact same tarball that we
>> produce.
>
> The varience in timestamp has been no problem for other projects
> including genkernel.  If all that varies is the time stamp and it
> matters to you, it would be easy to add a section to the Makefile
> setting the timestamp to a hardcoded value.
>
>
>> I see two ways around this: We can either make asciidoc a build time
>> dependency so that the user can use something like "make manpage" to
>> generate the manpage
>
> That adds quite some load on indirect dependencies for more or less
> nothing, as seen with Matt earlier.

For the live ebuild, I don't see any problem with this. I think we
just want to avoid having to install asciidoc for the released
catalyst versions.

>> or we can go back to the manpage that is in the git
>> repository.
>
> Do I have to list reasons against this option?

Yeah, this option is really distasteful.

I think the best solution is to simply hack the timestamp on the
generated files or something similar. We definitely don't want `emerge
=catalyst-2*` to require asciidoc and all its indirect dependencies
for a single man page, and we definitely don't want to check-in
generated files to git for a variety of reasons.

Matt

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Sebastian Pipping]

On 06/26/2011 06:10 AM, Matt Turner wrote:
> For the live ebuild, I don't see any problem with this. I think we
> just want to avoid having to install asciidoc for the released
> catalyst versions.

The tarballs are coming with a rendered man page - it is generated on
the machine running "make dist", not the machine installing catalyst.


>> Do I have to list reasons against this option?
> 
> Yeah, this option is really distasteful.

Thanks.


> I think the best solution is to simply hack the timestamp on the
> generated files or something similar. We definitely don't want `emerge
> =catalyst-2*` to require asciidoc and all its indirect dependencies
> for a single man page, and we definitely don't want to check-in
> generated files to git for a variety of reasons.

Again, see above.

Best,



Sebastian

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 705 bytes --]

On Sun, Jun 26, 2011 at 06:14:59AM +0200, Sebastian Pipping wrote:
> > I think the best solution is to simply hack the timestamp on the
> > generated files or something similar. We definitely don't want `emerge
> > =catalyst-2*` to require asciidoc and all its indirect dependencies
> > for a single man page, and we definitely don't want to check-in
> > generated files to git for a variety of reasons.

The thing about this approach though is, how do you know what timestamp
to put on the  generated files?

When you do:

git archive --prefix catalyst-x.x -o catalyst-x.x.tar catalyst_x_x

It takes the time/date from the tree some way and puts that time and
date on the files in the tarball.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Sebastian Pipping]

On 06/26/2011 06:44 AM, William Hubbs wrote:
> On Sun, Jun 26, 2011 at 06:14:59AM +0200, Sebastian Pipping wrote:
>>> I think the best solution is to simply hack the timestamp on the
>>> generated files or something similar. We definitely don't want `emerge
>>> =catalyst-2*` to require asciidoc and all its indirect dependencies
>>> for a single man page, and we definitely don't want to check-in
>>> generated files to git for a variety of reasons.
> 
> The thing about this approach though is, how do you know what timestamp
> to put on the  generated files?

You could pick a hardcode one.  If traball identity is the goal, any
fake timestamp will suffice.


> When you do:
> 
> git archive --prefix catalyst-x.x -o catalyst-x.x.tar catalyst_x_x
> 
> It takes the time/date from the tree some way and puts that time and
> date on the files in the tarball.

I'm aware.  I use git archive where I don't have generated content involved.



Sebastian

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Peter Volkov]

В Вск, 26/06/2011 в 00:10 -0400, Matt Turner пишет:
> On Sat, Jun 25, 2011 at 11:14 PM, Sebastian Pipping <sping@gentoo.org> wrote:
> >> I see two ways around this: We can either make asciidoc a build time
> >> dependency so that the user can use something like "make manpage" to
> >> generate the manpage
> >
> > That adds quite some load on indirect dependencies for more or less
> > nothing, as seen with Matt earlier.
> 
> For the live ebuild, I don't see any problem with this. I think we
> just want to avoid having to install asciidoc for the released
> catalyst versions.

Also if there is releng team requirement to have catalyst-9999 ebuild
without asciidoc dependency it'll be not hard to add USE doc or build -
man page is hardly required on automated stage generation servers.

--
Peter.

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Sebastian Pipping]

On 06/26/2011 04:02 AM, Matt Turner wrote:
> I get this when trying to do `EGIT_BRANCH="catalyst_2" emerge
> =catalyst-9999` I suppose because asciidoc isn't listed as a
> dependency.

Asciidoc dependency now added to live ebuild (revision 1.13).



Sebastian

Re: [gentoo-catalyst] Migrating man page to asciidoc?

[Peter Stuge]

Sebastian Pipping wrote:
> Asciidoc dependency now added to live ebuild (revision 1.13).

Cool. Thanks!

Now, if someone feels strongly about asciidoc dependencies, maybe
they can improve the asciidoc ebuild with more USE flags, so that
it becomes a much more lightweight dependency not only for catalyst,
but for *all* packages which use it.


//Peter