Re: TC nomination procedure v0
Sean Whitton dijo [Fri, Dec 01, 2017 at 01:57:01PM -0700]: > > So to answer your question specifically; I don't think the TC hides > > the numbers on purpose, it just doesn't really go through the effort > > of making them public. > > > > Another aspect there also is that we don't want to put anyone who > > entered the process under bad public light. Low numbers would help > > draw (probably wrong) conclusions if one knows about some nominations. > > Okay, thanks. > > A point on the other side is that it is good for the project to know > whether or not there is a healthy number of people putting themselves > forward for the TC. That is a fair point - At some point, I also¹ had the impression the TC was short of nominations. It can be healthy for applicants to know, not the identities perhaps, but the amount of people volunteering for the position. ¹ also, as AFAICT Wouter had this impression as well signature.asc Description: PGP signature
Re: TC nomination procedure v0
Hello Didier, On Fri, Dec 01 2017, Didier 'OdyX' Raboud wrote: > So to answer your question specifically; I don't think the TC hides > the numbers on purpose, it just doesn't really go through the effort > of making them public. > > Another aspect there also is that we don't want to put anyone who > entered the process under bad public light. Low numbers would help > draw (probably wrong) conclusions if one knows about some nominations. Okay, thanks. A point on the other side is that it is good for the project to know whether or not there is a healthy number of people putting themselves forward for the TC. -- Sean Whitton signature.asc Description: PGP signature
Bug#881339: maybe this one is solved but let's keep finding solutions together
On Fri, 01 Dec 2017, Paolo Greppi wrote: > Fourth to Don, many thanks for trying to find a clean technical > solution, but that won't work in this case because the babel makefile > bootstrap target does: > > yarn > ./node_modules/.bin/lerna bootstrap > make build > cd packages/babel-runtime; node scripts/build-dist.js > > and yarn and lerna are both WIP: > - yarn: https://bugs.debian.org/843021 > - lerna: https://bugs.debian.org/849258 yarn is a mechanism to manage build dependencies, and lerna is git submodule/split git repo manager. I'd expect that neither are required in Debian where sbuild manages the dependencies, and no remote sources are available. [I tried to see if this was the case, but babel seems to have very limited in-tree design documentation.] -- Don Armstrong https://www.donarmstrong.com Some pirates achieved immortality by great deeds of cruelty or daring-do. Some achieved immortality by amassing great wealth. But the captain had long ago decided that he would, on the whole, prefer to achieve immortality by not dying. -- Terry Pratchet _The Color of Magic_
Bug#881339: maybe this one is solved but let's keep finding solutions together
First the actual issue of this bug may be solved because we have found a technical solution by cheating a little bit on dependencies: https://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2017-December/022806.html https://anonscm.debian.org/cgit/pkg-javascript/node-babel-preset-env.git/tree/debian/patches/00-babelrc.patch Second ATM in debian node-babel-preset-env is separate from node-babel, but upstream moved it back into the main babel repo: https://github.com/babel/babel-preset-env/ "Now that babel-preset-env has stabilized, it has been moved into the main Babel mono-repo." So in the near future node-babel-preset-env may well be one of the binaries generated from node-babel source. And when that happens, babel will depend on itself because: https://github.com/babel/babel/blob/master/package.json#L15 Third considering the ephemeral nature of the boundaries between one package and another, I propose that we consider circular references in general, be them within a package or across packages. Fourth to Don, many thanks for trying to find a clean technical solution, but that won't work in this case because the babel makefile bootstrap target does: yarn ./node_modules/.bin/lerna bootstrap make build cd packages/babel-runtime; node scripts/build-dist.js and yarn and lerna are both WIP: - yarn: https://bugs.debian.org/843021 - lerna: https://bugs.debian.org/849258 and both depend on babel: https://wiki.debian.org/Javascript/Nodejs/Tasks/yarn https://wiki.debian.org/Javascript/Nodejs/Tasks/lerna so it's still a circular reference ! Now back to the issue, while it is certainly possible to bootstrap gcc, babel, rollup or any self-compiling compiler, how much skills and time it requires to achieve it once AND to keep it working when upstream moves on varies a lot. The bootstrap process of gcc for example is stable and supported by upstream. Once you have that, there is still a lot of work to set it up in debian, but if it works it is likely to keep working in the future. With certain javascript packages on the other hand, given that upstream is not in the business of systems programming and does not care about a clean, "orthodox" bootstrap, it can be harder to get once and even harder to keep working when upstream changes tooling, language versions ... The javascript team has very limited resources when confronted with the enthusiasms of upstream. The whole point of making debian or derivatives usable by javascript folk is the hope that with more debian users among them some may volunteer and channel some of their enthusiasm in integrating javascript tools and products within debian ! In conclusion I think it would be nice to be able to close this bug keeping in mind that we need to be a bit flexible with all this node-* stuff !
Re: TC nomination procedure v0
Wouter Verhelst writes ("Re: TC nomination procedure v0"):
> It's a vote that will have effect on the appointment of a person to the
> TC. The constitution specifically wants appointment votes to be public.
> Without wanting to comment on the letter, I think this is contrary to
> the intent.
>
> To be clear, I also think the consitution is wrong to require that such
> votes are public. I think the TC should not have to make appointments in
> public, for the very same reason that we also have secret ballots on DPL
> votes. However, I think the correct course of action here is not to
> ignore the constitution and explain that by some clever choice of words,
> but rather to amend the constitution to make it be in line with that
> rationale.
I suppose it would be worth explaining why I drafted this the way I
did, and what I intended.
The current system, with a private process including non-binding
filtering votes etc., followed by a public rubber stamp, is exactly
what I had in mind, and I still think it is the best way.
The reasons why most of the process has to be private are obvious.
The reasons for the formal binding vote to be public are less so, it
seems.
So: In a situation where there is rough consensus and every TC member
is content that the process is appropriate, then the public vote is
indeed a formality. That's simply a reflection of consensus generated
during the private discussion.
Often some participants in that consensus might have preferred
different candidate(s), considering the matter in a vacuum, but think
it more imporant to not to do the inevitable public personalised
discussion of possible appointments, than to force this issue. Such a
TC member will vote with the rest of the committee in the formal
public vote. That is fine.
But: if there is a lack of consensus on process, or a TC member feels
strongly enough to publicly dissent on a particular candidate, or
whatever, it is vital that that such a TC member has a way to dissent
which is simultaneously formally effective, and verifiable from
outside the TC. And likewise, that TC members who vote to overrule a
publicly dissenting member must do so in a way that is visible from
outside.
The alternative is a situation where, even when there is a serious
disagreement, TC members can mislead outsiders about the ultimate
position they took when the matter was finally decided by a vote.
Luckily such misleading statements are (I think) hypothetical, but the
question of dissent, and the need for formal public dissent, is not.
Sam Hartman indeed abstained on a recent TC appointment vote out of
unhappiness with the process. That is precisely the kind of thing
that cannot be done if the final vote is secret.
So that is why the private process within the TC must be ratified by a
public vote. (And it also ensures that any votes or polls which take
place in the private process are indicative, but are not binding on TC
members in the final vote.)
Ian.
Bug#881339: let's find a solution
Paolo Greppi writes ("Bug#881339: let's find a solution"):
> [some stuff about babel]
Can someone point me to a clear summary of ftpmaster's position ?
All I could find is this
http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2017-November/022197.html
Which contains the single sentence
| it is strange that the package Build-Depends: on itself!?
Lots of language compilers build-depend on themselves so surely there
is more to this.
Ian.
--
Ian JacksonThese 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.
Re: TC nomination procedure v0
Le jeudi, 30 novembre 2017, 14.03:15 h CET Wouter Verhelst a écrit : > On Tue, Nov 28, 2017 at 10:48:25AM -0800, Don Armstrong wrote: > > My rationale is that the private "vote" isn't a vote on the appointment, > > it's a vote to figure out whether the future appointment vote will have > > consensus or not. Given large sets of vetted nominees, it's can also be a "sorting" mechanism. We could have more consensual candidates than seats to fill at a certain point in time, so using a condorcet-based process (yes, that's the Standard Resolution Procedure) helps determining who has consensus _and_ is preferred at that point in time. We don't want to have to downvote someone in public, so we make sure the public ballot has only the preferred candidate and FD. This implies that: a) yes, the private vote is a preliminary vote on appointment; b) the public vote is usually a mere formality. (The public vote is only a formality given a relatively unanimous TC though; and we could have a TC split about whom they'd want to get onboard. The current process doesn't really address that hypothetical situation.) > It's a vote that will have effect on the appointment of a person to the > TC. The constitution specifically wants appointment votes to be public. > Without wanting to comment on the letter, I think this is contrary to > the intent. > > To be clear, I also think the consitution is wrong to require that such > votes are public. I think the TC should not have to make appointments in > public, for the very same reason that we also have secret ballots on DPL > votes. However, I think the correct course of action here is not to > ignore the constitution and explain that by some clever choice of words, > but rather to amend the constitution to make it be in line with that > rationale. Would you be interested in drafting a GR for that, or is that too premature? Cheers OdyX signature.asc Description: This is a digitally signed message part.
Re: TC nomination procedure v0
Le mardi, 28 novembre 2017, 14.26:05 h CET Sean Whitton a écrit :
> On Tue, Nov 28 2017, Didier 'OdyX' Raboud wrote:
> > - The TC *does not* make the number of nominees or number of
> > accepted nominations public.
>
> I'm curious to here the thinking behind this particular line of the
> procedure.
The current process is the result of multiple not-really-thought-through
iterations, and I don't think the TC ever really had an active conversation
about that specific item. But here's my take:
It's easier [0] to have only few "public moments" in that process.
* the TC says "we have free seats"
* (… something happens in private …)
* the TC says "we ask the DPL to fill that one seat with #{project_member}"
So to answer your question specifically; I don't think the TC hides the
numbers on purpose, it just doesn't really go through the effort of making
them public.
Another aspect there also is that we don't want to put anyone who entered the
process under bad public light. Low numbers would help draw (probably wrong)
conclusions if one knows about some nominations.
Cheers,
OdyX
[0] As in "it costs less spoons".
signature.asc
Description: This is a digitally signed message part.
