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

["Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org>]

-----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-----