Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Ansgar]

Ulrike Uhlig writes:
> On 26.09.19 08:03, Ansgar wrote:
>> What does stop the recommendations to be outdated in a year or two?
>> Given the long and slow process to gather them, there will probably be a
>> long and slow process to change them; that discourages actually changing
>> them (too high barrier).
>> 
>> In my opinion we already have similar problems with other
>> standards/documentation in Debian.
>
> Just to be clear, are you saying: because we think today that we cannot
> commit to maintain documentation we should rather live without it?

No.

> I personally believe that the current long and slow process is due to
> the fact that it is the first time that this process happens.

We already have a long and slow process for official technical
documentation.  There are things that changed a decade ago and aren't
yet updated.

For /recommendations/ which are much more subjective, I expect an even
longer and slower process to update them if someone puts them in written
form.

Ansgar

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Ulrike Uhlig]

Hi Holger,

On 24.09.19 15:21, Holger Levsen wrote:
> On Tue, Sep 24, 2019 at 08:10:39AM -0400, Sam Hartman wrote:
>> For several of these recommendations if I cannot get consensus, I will
>> call for a GR myself.
>  
> TBH, I'm not thrilled to read this, though of course it's in your rights
> to do that. (I'm afraid such GRs would cost a lot of time which could be
> better spent elsewhere. Of course I might be wrong about this and the
> outcome of those GRs will be worth them.)
> 
> OTOH I'd be thrilled to see some progress on reimbursing BSP participants
> and similar stuff. As I see it, the next BSP will happen in a month in 
> Vaumarcus...

I find the tone of your objection quite passive aggressive (like most of
your emails that I accidentally read during the past weeks or months on
diverse Debian lists).

That said, if you believe there should be a way to prioritize issues
over other issues, it could be possibly be a process that is actually
negotiated, pain points identified collectively (answering the question
"why did it not happen yet?"), and the issue solved in a respectful way.

Kind regards,
Ulrike

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Ulrike Uhlig]

Hi!

On 26.09.19 08:03, Ansgar wrote:
> Enrico Zini writes:
>> On Tue, Sep 24, 2019 at 08:27:15PM -0400, Sam Hartman wrote:

>> Also, as over time my packaging practices have become outdated, I have
>> found it both difficult and frustrating to engage on a quest for
>> figuring out "how does one do this thing nowadays?"[1], and if there
>> were default recommendations available, I would have considered them a
>> boon[2].
> 
> What does stop the recommendations to be outdated in a year or two?
> Given the long and slow process to gather them, there will probably be a
> long and slow process to change them; that discourages actually changing
> them (too high barrier).
> 
> In my opinion we already have similar problems with other
> standards/documentation in Debian.

Just to be clear, are you saying: because we think today that we cannot
commit to maintain documentation we should rather live without it?

I personally believe that the current long and slow process is due to
the fact that it is the first time that this process happens. Logically,
every subsequent time will be faster, because there will already be a
basis. It will easier to change an existing piece of documentation than
to research and rewrite it from scratch. And yes, documentation needs
the same kind of maintenance as packages themselves :)

Cheers!
Ulrike

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Ansgar]

Enrico Zini writes:
> On Tue, Sep 24, 2019 at 08:27:15PM -0400, Sam Hartman wrote:
>> But I think having recommendations available when people are new, when
>> they are looking for what to do when writing new tools, when the trade
>> offs don't matter, is really important.  I think it's important enough
>> that it's worth time for a quick vote (and I do believe we can
>> efficiently handle GRs).
[...]
> Also, as over time my packaging practices have become outdated, I have
> found it both difficult and frustrating to engage on a quest for
> figuring out "how does one do this thing nowadays?"[1], and if there
> were default recommendations available, I would have considered them a
> boon[2].

What does stop the recommendations to be outdated in a year or two?
Given the long and slow process to gather them, there will probably be a
long and slow process to change them; that discourages actually changing
them (too high barrier).

In my opinion we already have similar problems with other
standards/documentation in Debian.

Ansgar

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Enrico Zini]

On Tue, Sep 24, 2019 at 08:27:15PM -0400, Sam Hartman wrote:

> But I think having recommendations available when people are new, when
> they are looking for what to do when writing new tools, when the trade
> offs don't matter, is really important.  I think it's important enough
> that it's worth time for a quick vote (and I do believe we can
> efficiently handle GRs).

I agree with your message, and I'd like to expand on "when people are
new". I probably don't qualify as new in Debian, and I maintain some
package outside of teams. For those packages, I suffer from the lack of
a team policy that gives me a default way of doing things unless I have
better ideas.

Also, as over time my packaging practices have become outdated, I have
found it both difficult and frustrating to engage on a quest for
figuring out "how does one do this thing nowadays?"[1], and if there
were default recommendations available, I would have considered them a
boon[2].

When the upstream is straightforward and I'm not engaging in innovating
packaging practices, I'm significantly happier having a default script
that I can follow, instead of reinventing or refiguring out the wheel
every time I have an upload to make[3].

So, maybe I'm not new in Debian, but Debian is often new to me, When
there's no team to provide me with some well thought defaults, I could
use a well documented set of well thought defaults to work with.


Enrico

[1] if one finds themselves in a similar position, a good way of staying
up to date is to become Application Manager. AMs routinely learn a
lot from applicants
[2] maybe with some policy-style upgrading checklists
[3] the things I maintain don't need frequent uploads, and it's become
sort of my expectation that for each upload that I make I need to
plan some nontrivial yak shaving time to figure out which of my
assumptions have become invalid since the last one
-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Ole Streicher]

Mo Zhou  writes:
> Is the recommendation working well under most circumstances?
> I mean, different teams have already made their conventions
> at these point, such as go team, rust team, nvidia team, etc.
> These team designed "local" recommendations always adapt
> well with special property of their corresponding ecosystems.
> Designing a convincing "global" recommendation that works
> nearly everywhere is difficult.

Is there an overview how many teams deviate from the proposed
recommendations, and how much? Maybe first these teams should be
convinced; this would already give a big impact.

(I have no idea here; the teams where I am contribute to seem to be all
more or less in line)

Cheers

Ole

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Sam Hartman]

> "Mo" == Mo Zhou  writes:

Mo> As you said, recommendations are merely recommendations.  Debian
Mo> developers customed to their own workflow may not necessarily
Mo> follow the recommendations. However, the recommendation makes a
Mo> difference for newbies or newcomers, if their arbitrary
Mo> educational resources share uniformed recommends. To some extent
Mo> I think debian development is destined to be diversified.

Right, and people new to the process is one of the big motivators for
me.

It looks like we'll get the recommendations via consensus and we won't
need GRs.

But I think having recommendations available when people are new, when
they are looking for what to do when writing new tools, when the trade
offs don't matter, is really important.  I think it's important enough
that it's worth time for a quick vote (and I do believe we can
efficiently handle GRs).

Besides, I did say in the campaign period I was going to work towards
recommendations/policy in this space.  You shouldn't be surprised I'll
use all the tools available to me to accomplish my goals.  I'm always
open to changing my mind, but what I've seen so far has re-enforced the
idea that more uniformity would be good for Debian rather than
challenging it.

--Sam

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Mo Zhou]

On 2019-09-25 07:15, Sam Hartman wrote:
>> "Scott" == Scott Kitterman  writes:
> 
> >> For several of these recommendations if I cannot get consensus, I
> >> will call for a GR myself.
> 
> Scott> What do you think is important enough in this area that you
> Scott> would rather have people not contribute to Debian if they
> Scott> aren't willing to do it your way?
> 
> Nothing.
> The thing about recommendations is that you don't have to follow them.
> 
> I think that recommendations leading toward more uniform practices have
> huge value even if  some people don't follow them.

Is the recommendation working well under most circumstances?
I mean, different teams have already made their conventions
at these point, such as go team, rust team, nvidia team, etc.
These team designed "local" recommendations always adapt
well with special property of their corresponding ecosystems.
Designing a convincing "global" recommendation that works
nearly everywhere is difficult.

While designing ML-policy I discovered that it's easy
to find exceptions to break the global rules.

> And eventually, when we have enough experience it might well be that
> having more uniformity is worth some people not directly contributing to
> Debian.
> I don't know if we'll ever make that trade off and I know we wouldn't
> (and shouldn't) make it today.

As you said, recommendations are merely recommendations.
Debian developers customed to their own workflow may
not necessarily follow the recommendations. However, the
recommendation makes a difference for newbies or newcomers,
if their arbitrary educational resources share uniformed
recommends. To some extent I think debian development is
destined to be diversified.

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Scott Kitterman]

On September 24, 2019 11:15:33 PM UTC, Sam Hartman  wrote:
>> "Scott" == Scott Kitterman  writes:
>
>   >> For several of these recommendations if I cannot get consensus, I
>>> will call for a GR myself.
>
>Scott> What do you think is important enough in this area that you
>Scott> would rather have people not contribute to Debian if they
>Scott> aren't willing to do it your way?
>
>Nothing.
>The thing about recommendations is that you don't have to follow them.
>
>I think that recommendations leading toward more uniform practices have
>huge value even if  some people don't follow them.
>And eventually, when we have enough experience it might well be that
>having more uniformity is worth some people not directly contributing
>to
>Debian.
>I don't know if we'll ever make that trade off and I know we wouldn't
>(and shouldn't) make it today.

Then I certainly don't understand why you are considering a GR or three.  
Documenting recommendations doesn't really require it.  Agreeing something is 
generally a good idea is much different than requiring it.

Scott K

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Mo Zhou]

On 2019-09-25 05:32, Bernd Zeimetz wrote:
> On 9/24/19 3:21 PM, Holger Levsen wrote:
>> On Tue, Sep 24, 2019 at 08:10:39AM -0400, Sam Hartman wrote:
>>> For several of these recommendations if I cannot get consensus, I will
>>> call for a GR myself.
>>
>> TBH, I'm not thrilled to read this, though of course it's in your rights
>> to do that. (I'm afraid such GRs would cost a lot of time which could be
>> better spent elsewhere. Of course I might be wrong about this and the
>> outcome of those GRs will be worth them.)
> 
> ack...
> 
>> OTOH I'd be thrilled to see some progress on reimbursing BSP participants
>> and similar stuff. As I see it, the next BSP will happen in a month in
>> Vaumarcus...
> 
> and ack...
> 
> There are way more important things to do than to discuss the place of
> git repositories.

Agreed. What I can do for this thread is marking mails
as read and voting for objection if I was required to act.

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Sam Hartman]

> "Scott" == Scott Kitterman  writes:

>> For several of these recommendations if I cannot get consensus, I
>> will call for a GR myself.

Scott> What do you think is important enough in this area that you
Scott> would rather have people not contribute to Debian if they
Scott> aren't willing to do it your way?

Nothing.
The thing about recommendations is that you don't have to follow them.

I think that recommendations leading toward more uniform practices have
huge value even if  some people don't follow them.
And eventually, when we have enough experience it might well be that
having more uniformity is worth some people not directly contributing to
Debian.
I don't know if we'll ever make that trade off and I know we wouldn't
(and shouldn't) make it today.

--Sam

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Bernd Zeimetz]

On 9/24/19 3:21 PM, Holger Levsen wrote:
> On Tue, Sep 24, 2019 at 08:10:39AM -0400, Sam Hartman wrote:
>> For several of these recommendations if I cannot get consensus, I will
>> call for a GR myself.
>  
> TBH, I'm not thrilled to read this, though of course it's in your rights
> to do that. (I'm afraid such GRs would cost a lot of time which could be
> better spent elsewhere. Of course I might be wrong about this and the
> outcome of those GRs will be worth them.)

ack...

> OTOH I'd be thrilled to see some progress on reimbursing BSP participants
> and similar stuff. As I see it, the next BSP will happen in a month in 
> Vaumarcus...

and ack...

There are way more important things to do than to discuss the place of
git repositories.




-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Bernd Zeimetz]

Hi,

On 9/24/19 8:45 AM, Thomas Goirand wrote:
> Why would it be unacceptable that the whole of the archive be maintained
> in Git using Salsa? Wouldn't it be much nicer for everyone?

basically because sometimes it makes sense to have packages on github
(or gitlab, ...), close (or even within) upstream repositories.

While they could be mirrored to salsa, it wouldn't make sense, as this
would be a read only mirror.

Also salsa's CI runner is still missing resources, so right now it also
makes sense not to migrate everything there - travis is happily giving
resources out for free.


Bernd


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Scott Kitterman]

On September 24, 2019 12:10:39 PM UTC, Sam Hartman  wrote:
>> "Bernd" == Bernd Zeimetz  writes:
>
>Bernd> On 7/23/19 7:31 PM, Thomas Goirand wrote:
>>> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using
>>> Git for packaging.
>
>   Bernd> why is that a reason for a GR?  its a question for the policy
>Bernd> editors.
>
>So, I agree that a GR would be the wrong approach if we thought that we
>could get to a consensus strong enough for the policy editors.
>
>I also agree that the policy editors have the technical authority to
>use
>a different (non-consensus) process and simply change policy.  The
>policy editors have chosen not to do that sort of thing for a variety
>of
>reasons.  Personally I think they have judged the needs of the project
>well.  I think that the project would generally be unhappy if the
>policy
>editors simply used their best technical judgment to set policy rather
>than following a consensus process.
>
>It seems quite clear that the existing policy process would not come to
>consensus on any of Thomas's points.
>So, if we did want to get to a firm policy, I think a GR would be the
>right tool.
>
>I hear that you'd vote against such a GR.
>Just because you would vote against doesn't mean the GR is a wrong
>tool.
>
>Personally I think that aGR mandating Git on Salsa would fail.
>I'm trying in a consensus discussion to get to recommendations (rather
>than requirements) along the lines that Thomas was asking for.
>
>Thomas could try to take some of those recommendations to requirements
>with a GR if he chooses.
>
>For several of these recommendations if I cannot get consensus, I will
>call for a GR myself.

What do you think is important enough in this area that you would rather have 
people not contribute to Debian if they aren't willing to do it your way?

Scott K

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Sean Whitton]

Hello,

On Tue 24 Sep 2019 at 08:10AM -04, Sam Hartman wrote:

> So, I agree that a GR would be the wrong approach if we thought that we
> could get to a consensus strong enough for the policy editors.
>
> I also agree that the policy editors have the technical authority to use
> a different (non-consensus) process and simply change policy.  The
> policy editors have chosen not to do that sort of thing for a variety of
> reasons.  Personally I think they have judged the needs of the project
> well.  I think that the project would generally be unhappy if the policy
> editors simply used their best technical judgment to set policy rather
> than following a consensus process.
>
> It seems quite clear that the existing policy process would not come to
> consensus on any of Thomas's points.
> So, if we did want to get to a firm policy, I think a GR would be the
> right tool.

Right.  It's difficult to imagine us getting consensus on these points
via that process.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Holger Levsen]

On Tue, Sep 24, 2019 at 08:10:39AM -0400, Sam Hartman wrote:
> For several of these recommendations if I cannot get consensus, I will
> call for a GR myself.
 
TBH, I'm not thrilled to read this, though of course it's in your rights
to do that. (I'm afraid such GRs would cost a lot of time which could be
better spent elsewhere. Of course I might be wrong about this and the
outcome of those GRs will be worth them.)

OTOH I'd be thrilled to see some progress on reimbursing BSP participants
and similar stuff. As I see it, the next BSP will happen in a month in 
Vaumarcus...


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Sam Hartman]

> "Bernd" == Bernd Zeimetz  writes:

Bernd> On 7/23/19 7:31 PM, Thomas Goirand wrote:
>> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using
>> Git for packaging.

Bernd> why is that a reason for a GR?  its a question for the policy
Bernd> editors.

So, I agree that a GR would be the wrong approach if we thought that we
could get to a consensus strong enough for the policy editors.

I also agree that the policy editors have the technical authority to use
a different (non-consensus) process and simply change policy.  The
policy editors have chosen not to do that sort of thing for a variety of
reasons.  Personally I think they have judged the needs of the project
well.  I think that the project would generally be unhappy if the policy
editors simply used their best technical judgment to set policy rather
than following a consensus process.

It seems quite clear that the existing policy process would not come to
consensus on any of Thomas's points.
So, if we did want to get to a firm policy, I think a GR would be the
right tool.

I hear that you'd vote against such a GR.
Just because you would vote against doesn't mean the GR is a wrong tool.

Personally I think that aGR mandating Git on Salsa would fail.
I'm trying in a consensus discussion to get to recommendations (rather
than requirements) along the lines that Thomas was asking for.

Thomas could try to take some of those recommendations to requirements
with a GR if he chooses.

For several of these recommendations if I cannot get consensus, I will
call for a GR myself.

--Sam

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Thomas Goirand]

Hi,

You may have noticed that the DPL asked me to put this thread on hold,
as he's discussing it in -devel. I've therefore given-up. However, let
me still answer.

On 9/23/19 8:45 PM, Bernd Zeimetz wrote:
> Also you would force everybody to use git, so this is not acceptable at all.
>
>> 3- Mandating using Salsa as a Git repository.
> 
> If that would really pass a GR, I'll start to remove packages from
> Debian

Why would it be unacceptable that the whole of the archive be maintained
in Git using Salsa? Wouldn't it be much nicer for everyone?

Cheers,

Thomas Goirand (zigo)

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Bernd Zeimetz]

On 7/23/19 7:31 PM, Thomas Goirand wrote:
> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
> packaging.

why is that a reason for a GR?
its a question for the policy editors.
Also you would force everybody to use git, so this is not acceptable at all.


> 2- Mandating using the "gbp patches unapplied" layout for Git, as this
> seems to be the most popular layout, and that we need some kind of
> consistency.

no, thanks. Thats also not a thing to decide in a GR.


> 3- Mandating using Salsa as a Git repository.

If that would really pass a GR, I'll start to remove packages from
Debian



> 
> I do believe #1 will pass easily, but that it's useless without #2, and
> there is some kind of uncertainty. For #3, I'm not even sure we should
> vote for that, I probably even prefer it not to be voted for myself,
> though what's annoying me is having to pull some packaging from non-free
> services such as Github, and this would make an end to it.
> 
> Please do devide your replies clearly on the 3 topics. If you see other
> topics that should be discussed, please identify them clearly as well.
> 
> For those not convinced yet on the utility of such a GR, just think
> about a few months/years from now, where we will be 100% sure that
> absolutely all packages will be hosted on Salsa (or another system we
> decide to migrate to) with the same Git layout, and how easy it will be
> (for example) to add some kind of CI/CD for all packages.
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Thomas Goirand]

On 8/27/19 10:25 AM, Norbert Preining wrote:
> Hi,
> 
>> Norbert, I'm very annoyed by your wording. "Having an agenda" reads like
>> if I was writing out of malice, on purpose, just to annoy you. That is
> 
> No, having an agenda is that you have a clear target which you want to
> achieve.

That's the way *you* feel about it. Not mine. I feel offended, because
"acting out of malice" is what I feel when reading you. So yeah, please
more carefully choose your words.

> Wrong. [...]
> 
> So please, don't assume anthing about what I think and read my
> intentions. Thanks.

What's funny is that what you expressed above is exactly what I assumed,
and understood without more explanation.

Cheers,

Thomas Goirand (zigo)

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Guillem Jover]

On Mon, 2019-08-26 at 23:59:09 +0200, Thomas Goirand wrote:
> On 7/26/19 4:40 PM, Andy Simpkins wrote:
> > Personally I see no reason to mandate such a change, with policy only
> > recommending / preferring the proposed changes. Furthermore I accept
> > that the policy should strongly recommend (i.e. require an explanation
> > why not) for NEW packages.

> As per our discussion in Debconf, we're attempting to remove Python 2
> from Bullseye. So, I decided to commit myself to try to do one Python 2
> removal per day. Doing so, I often encounter very badly maintained
> packages (ie: far behind upstream, bugs, no py3 support even if upstream
> has it, you name it...). And often, I get these packages maintained on a
> proprietary platform, where I have no write access. As a result, I'm
> forced to either register on the said non-free platform, and use a
> workflow which I very much dislike. It's either that ... or I just
> ignore the VCS fields, and the VCS becomes outdated, missing my upload,
> with a very good chance that it will never get updated. That's really
> bad for any future contributor that probably will also encounter the
> same problem, with on top, my changes not commited. Add on top of this
> that when you do 'apt-get source foo', then apt suggests to fetch the
> sources from that non-free platform, which has outdated sources. How do
> you explain this to a Debian newbie that wants to start contributing to
> Debian? This really doesn't make sense at all.

I read a mass of conflated arguments there that make any such
discussion quite difficult IMO.


I fully understand, and agree myself with, not wanting to use a
proprietary platform as the *primary* site for one's projects, to
avoid lock-in, to support free-software ideals, etc. I do have
accounts, and even secondary mirrors on some of these though.

As maintainers we are expected to interact with upstreams, and submit
our changes there (not just for others benefit, but also for our own,
to avoid future conflicting changes, and to make Debian needs known),
which seems it would still be unnacceptable to you. Should we then ban
any such upstream from getting into Debian? That seems like a complete
non-starter TBH, or do you expect that's fine, but someone else then
needs to do the dirty work for you? If so, what's the difference with
people in Debian maintaining the packages wherever?


Another thing I extract from your reply is that you are assuming we'd
have all repos in salsa being write-for-all, and using the debian/
namespace. That implies a very big social change, with many as yet
undefined social norms, that feels being sneaked in as an aside.


There's also the problem with out-of-date repos or unmaintained
packages. We are supposed to file NMU bugs with patches anyway. I've
also seen repos being out-of-sync with what it's in the archive on
*salsa*. The problem with unresponsive maintainers has not really
changed, we have procedures for that. I don't see why people that
cannot upload to the Debian archive should expect to be able to
automatically have write-access to random packaging repos either?
(And this all seems rather odd, given that we are talking about git,
while _D_VCS being one of its common selling points.)


There's also the problem with the workflows. I find anything that is
not packaging-only to be so attrocious to deal with that I rather
prefer to use «apt source» and go from there. I also extract from your
reply you'd like to force a single packaging workflow. Having to do
my packaging work on anything that is not packaging-only would make
that work miserable for me.


And then there's the «force to use salsa». I've got a few secondary
mirrors there too (such as for the dpkg suite), and I use the platform
(in the same way I'd use github or others) to interact with packagers
or upstreams that host there, but I'd be extremely unhappy with being
forced to use it. And I'd rather remove the Vcs fields from the packages
I maintain. See  for
some of reasons why I didn't switch the dpkg suite to salsa. For the
other package I maintain, I switched away from Alioth long long time
ago, and have been very happy since. Alioth was also supposed to be
a long-term hosting platform, but TBH I expect my self-hosting to last
longer than Salsa too.


> How do you handle such case, if not enforcing some kind of rules? Well,
> that's what motivated me to start this discussion. However, I'll let Sam
> take over, and see how it develops.

We already have procedures (NMUs, salvaging, etc) and common
infrastructure (Debian Archive, Debian source, BTS, etc) for everything
you describe above. I only see gratuituous enforcement for one's
preferred options here TBH. :(

Thanks,
Guillem

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Norbert Preining]

Hi,

> Norbert, I'm very annoyed by your wording. "Having an agenda" reads like
> if I was writing out of malice, on purpose, just to annoy you. That is

No, having an agenda is that you have a clear target which you want to
achieve.

> Reality is that you have no such opinion, you are just (rightly) pissed
> by the recent event around your account being revoked, then reinstalled.
> Also, this has to do with the foo-guest -> foo (and the other way around
> in your case), which needs to be fixed anyways. So this is IMO not
> relevant at all here.

Wrong. I simply realized that a system that is managed by a few
personals with rather free reign on what to do is not where I want to
work. You say github is nonfree, but removing rights on gh is
practically impossible, I don't know whether it actually happened. 

I don't care for the nuclear case that MS decides to shut down gh from
one day to the next. The same can happen due to other reasons with
salsa, too - and we have seen this just last months. That is not the
problem, git has everything I care for, so I can just push somewhere
else.

I care more for arbitrary actions. And I don't want to say that the
removal of my access was an arbitrary action, but I want to say that
arbitrary actions are just too easy to happen on salsa with a small
management team, personal preferences and ideals. So simply put, I don't
trust that in future something similar might not happen out of different
and even more strange reasons, while I am quite sure that on GH this
will *not* happen. And I consider this more likely than the nuclear
action of GH closing down.

So please, don't assume anthing about what I think and read my
intentions. Thanks.

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Thomas Goirand]

On 8/27/19 2:06 AM, Norbert Preining wrote:
> Hi
> 
> On Mon, 26 Aug 2019, Thomas Goirand wrote:
>> forced to either register on the said non-free platform, and use a
>> workflow which I very much dislike. It's either that ... or I just
>> ignore the VCS fields, and the VCS becomes outdated, missing my upload,
>> with a very good chance that it will never get updated. That's really
> 
> You are mixing unresponsiveness of the maintainer with non-free
> platforms

Well, the mix is indeed the problem!

> and I am sure you do that on purpose to press your own agenda
> to force everyone to salsa.

It's on purpose, because that's the problem, not because I'm acting out
of malice (ie: with an "agenda" that I need to "press") to annoy you.

Except yourself, and for obvious reasons which you already mentioned, I
haven't seen any opposition to the proposal.

> With any proposal like this the net effect is that those who prefer some
> other infrastructure than salsa will have an out of date git repo at
> salsa to satisfy your agenda, and real development will still continue
> somewhere else.

Norbert, I'm very annoyed by your wording. "Having an agenda" reads like
if I was writing out of malice, on purpose, just to annoy you. That is
not the case. I just happen to have a different view on things. It's
been told to you many times, your choice of words looks very aggressive
to others, and it'd be nice if that changed.

> Please, stop you crusade, and simply accept that other developers have
> other opinions than yours, and other preferences.

Reality is that you have no such opinion, you are just (rightly) pissed
by the recent event around your account being revoked, then reinstalled.
Also, this has to do with the foo-guest -> foo (and the other way around
in your case), which needs to be fixed anyways. So this is IMO not
relevant at all here.

Thomas Goirand (zigo)

dpatch was: Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Scott Kitterman]

On Monday, August 26, 2019 6:01:05 PM EDT Thomas Goirand wrote:
> On 7/26/19 6:53 PM, Scott Kitterman wrote:
> > It's true it's not extinct, but it's close.  It's only used by several
> > dozen packages now.  If someone wanted to push to get dpatch completely
> > out of the archive this cycle, I think it would be perfectly reasonable. 
> > The project has voted with their feet.
> 
> I wish we had release goals again, because that would really be a
> perfect fit.
> 
> Do you have the list of affected package available? How about we tackle
> this in a sprint, let's say, in Vaumarcus?

Here's the packages with dpatch in build-depends (they would all need checking 
- I assume lintian only uses it for its test suite):

reverse-depends -b dpatch
Reverse-Build-Depends
=
* bopm
* cadaver
* check-mk
* cryptcat
* docbook2odf
* dvbsnoop
* efax
* elscreen
* flexbackup
* flow-tools
* gkrellm-x86info
* ibam
* ippl
* libdumbnet
* libmdsp
* lifelines
* lintian
* manpages-es
* mgetty
* myspell
* noweb
* nwall
* ocaml-expat
* ocamlodbc
* python-authkit
* python-toscawidgets
* qmc
* readline5
* redet
* scim-canna
* scim-skk
* shanty
* spell
* synaptic
* syrep
* tapecalc
* tcm
* txt2regex
* vdk2
* vsdump
* wbox
* xaw3d
* xcal
* xsysinfo
* xxgdb

Scott K

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Norbert Preining]

Hi

On Mon, 26 Aug 2019, Thomas Goirand wrote:
> forced to either register on the said non-free platform, and use a
> workflow which I very much dislike. It's either that ... or I just
> ignore the VCS fields, and the VCS becomes outdated, missing my upload,
> with a very good chance that it will never get updated. That's really

You are mixing unresponsiveness of the maintainer with non-free
platforms, and I am sure you do that on purpose to press your own agenda
to force everyone to salsa.

Even on salsa there are (I am sure, because I have seen them before)
packages that are out of date, and you will not be able to push to it if
it is a personal project.

It boils down to responsiveness and collaborativenss of the maintainer,
and is not a question of non-free or not.

With any proposal like this the net effect is that those who prefer some
other infrastructure than salsa will have an out of date git repo at
salsa to satisfy your agenda, and real development will still continue
somewhere else. I for my side will not move over again, and if I am
forced I will just force-push released versions in one big bunch, and nothing
else, while actual development will happen somewhere else.


Please, stop you crusade, and simply accept that other developers have
other opinions than yours, and other preferences. We are volunteers.


Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Thomas Goirand]

On 7/26/19 6:53 PM, Scott Kitterman wrote:
> It's true it's not extinct, but it's close.  It's only used by several dozen 
> packages now.  If someone wanted to push to get dpatch completely out of the 
> archive this cycle, I think it would be perfectly reasonable.  The project 
> has 
> voted with their feet.

I wish we had release goals again, because that would really be a
perfect fit.

Do you have the list of affected package available? How about we tackle
this in a sprint, let's say, in Vaumarcus?

Cheers,

Thomas Goirand (zigo)

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Thomas Goirand]

On 7/26/19 4:40 PM, Andy Simpkins wrote:
> Hi all
> 
> It seams to me reading this thread that there are those who would like
> to mandate the use of a given VCS on a particular host.
> 
> The primary advantages being that it makes CI so much simpler, and
> having a uniform workflow makes it easier for those not maintaining a
> given package to view and make changes (occasionally distribution wide).
> 
> On the other hand there is also those who would rather not see this
> become mandatory.  Various reasons have been given, but if I have
> understood correctly they boil down to a few classes namely; doesn't
> fit our model, a lot or work to change for few if any perceived benefit,
> principled belief that maintainer is free to maintain however
> they see fit.
> 
> Personally I see no reason to mandate such a change, with policy only
> recommending / preferring the proposed changes. Furthermore I accept
> that the policy should strongly recommend (i.e. require an explanation
> why not) for NEW packages.

Consider this...

As per our discussion in Debconf, we're attempting to remove Python 2
from Bullseye. So, I decided to commit myself to try to do one Python 2
removal per day. Doing so, I often encounter very badly maintained
packages (ie: far behind upstream, bugs, no py3 support even if upstream
has it, you name it...). And often, I get these packages maintained on a
proprietary platform, where I have no write access. As a result, I'm
forced to either register on the said non-free platform, and use a
workflow which I very much dislike. It's either that ... or I just
ignore the VCS fields, and the VCS becomes outdated, missing my upload,
with a very good chance that it will never get updated. That's really
bad for any future contributor that probably will also encounter the
same problem, with on top, my changes not commited. Add on top of this
that when you do 'apt-get source foo', then apt suggests to fetch the
sources from that non-free platform, which has outdated sources. How do
you explain this to a Debian newbie that wants to start contributing to
Debian? This really doesn't make sense at all.

How do you handle such case, if not enforcing some kind of rules? Well,
that's what motivated me to start this discussion. However, I'll let Sam
take over, and see how it develops.

Cheers,

Thomas Goirand (zigo)

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Scott Kitterman]

On Thursday, July 25, 2019 11:02:14 PM EDT gregor herrmann wrote:
> On Wed, 24 Jul 2019 12:23:42 +, Scott Kitterman wrote:
> > We are
> > perfectly capable of phasing out obsolete workflows without a
> > hammer like a GR (remember dpatch).
> 
> Unrelated to the general topic but since you mention it: Yes I
> remember dpatch -- it's not phased out, I just encountered it a few
> days ago.

It's true it's not extinct, but it's close.  It's only used by several dozen 
packages now.  If someone wanted to push to get dpatch completely out of the 
archive this cycle, I think it would be perfectly reasonable.  The project has 
voted with their feet.

Scott K

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Tobias Frost]

On Fri, Jul 26, 2019 at 11:40:31AM -0300, Andy Simpkins wrote:
> Hi all

(...)

> /Andy

Thanks Andy for putting that into words, I completly agree with you.

-- 
tobi

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[gregor herrmann]

On Wed, 24 Jul 2019 12:23:42 +, Scott Kitterman wrote:

> We are
> perfectly capable of phasing out obsolete workflows without a
> hammer like a GR (remember dpatch).

Unrelated to the general topic but since you mention it: Yes I
remember dpatch -- it's not phased out, I just encountered it a few
days ago.


Cheers,
gregor 

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Tollef Fog Heen]

]] Thomas Goirand

> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
> packaging.

Like Steve said, there are cases where git is not the right
tool. Recommending, fine.  Mandating?  No, I think that would be a bad
idea.

> 2- Mandating using the "gbp patches unapplied" layout for Git, as this
> seems to be the most popular layout, and that we need some kind of
> consistency.

It seems to be self-evident to you that we need consistency.  It's not
at all clear to me that having a single layout to rule them all is the
right path forward.  Why do you think we should just have a single
layout?

Beyond that, I think we should move away from patches-unapplied rather
than towards it.  If you look at how normal software development is done
today, it's done with a git repo and not shuffling patches-as-files back
and forth.

I also think that having a single way of solving a problem will keep us
back from further evolution.  Freedom to experiment is useful, and by
having this as a GR, the only way forward from this would be to have
another GR to change to something else.  Binding ourselves that way
doesn't seem wise.

As for what you wrote downthread about possible to use 1.0 native
packages: yes,

> 3- Mandating using Salsa as a Git repository.

Again I think this proposal fails to account for corner cases, as an
example on top of what other have talked about: this could end up
affecting what can go into non-free.  This would also increase coupling,
something we already have a problem with, and which is considered a bad
idea in software development.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Scott Kitterman]

On July 25, 2019 9:46:08 AM UTC, Vincent Bernat  wrote:
> ❦ 24 juillet 2019 21:29 +00, Scott Kitterman :
>
 This entire discussion feels to me like a small group of developers
 trying to tell the rest of us "my way or the highway". We are
 perfectly capable of phasing out obsolete workflows without a
>hammer
 like a GR (remember dpatch).
>>>
>>>Without a GR, the outcome is decided by a shouting contest. A GR
>seeems
>>>great to know if people are a majority or not.
>>
>> 50% + 1 of developers mandating details like this to 50% - 1 of
>> developers is a horrible way to solve problems like this.
>
>Still better than 10% mandating details like this to 90%.
>
>> If you want people to do things a certain way, have it solve problems
>> that cause people to decide they want to use it. Once you get rough
>> consensus on the new way, change policy.
>
>So, this is the shouting contest. A few people can post messages and
>make it appear there is no consensus.

Usually consensus doesn't magically appear.  It takes work.  At this juncture 
none exists.  The idea of solving this via GR seems to me like an attempt to 
avoid doing that work.

I'm curious who from amongst those pushing for this is volunteering to put all 
the QA maintained packages in git (or should those be removed)?  If you are 
going to mandate this, then I think those are the only two options.

Scott K

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Vincent Bernat]

 ❦ 24 juillet 2019 21:29 +00, Scott Kitterman :

>>> This entire discussion feels to me like a small group of developers
>>> trying to tell the rest of us "my way or the highway". We are
>>> perfectly capable of phasing out obsolete workflows without a hammer
>>> like a GR (remember dpatch).
>>
>>Without a GR, the outcome is decided by a shouting contest. A GR seeems
>>great to know if people are a majority or not.
>
> 50% + 1 of developers mandating details like this to 50% - 1 of
> developers is a horrible way to solve problems like this.

Still better than 10% mandating details like this to 90%.

> If you want people to do things a certain way, have it solve problems
> that cause people to decide they want to use it. Once you get rough
> consensus on the new way, change policy.

So, this is the shouting contest. A few people can post messages and
make it appear there is no consensus.
-- 
Document your data layouts.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Florian Weimer]

* Vincent Bernat:

> Because without uniformity, we make it harder for people to contribute.
> I have already mentioned Fedora that provides everything in git with CI
> enabled, ability to contribute with pull requests, but that's far the
> only proponent.

Fedora still uses VCS-in-VCS, so it's not real Git.  You cannot simply
send a pull request for anything that changes source code.  You still
have to create a patch file and add it to the RPM spec file.  Some
package maintainers have their true repositories elsewhere and
synthesize the patches from that, but there's no standard way of doing
that yet.  (packit is not yet integrated with Fedora infrastructure,
and it is quite new.  It's unclear if it will fare better than the
many previous attempts.)

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Adam Borowski]

On Wed, Jul 24, 2019 at 12:23:42PM +, Scott Kitterman wrote:
> Since use of a public VCS isn't universal among free software projects,
> the implication is that one could take a non-free upstream tarball, dump
> it into git on salsa and magically make it free.  I think this is a
> ridiculous concept.

The concept of "preferred form for modification" is mostly about those who
actually do the work.  If there's an active upstream taking a drive-by
patch, it's the upstream's opinion that matters.

Dumping a tarball into git doesn't restore lost commit messages, patch
history, nor authorship data -- just like you can't un-preprocess C code
(nVidia's "nv" driver comes to mind).

Ie, I consider making matters worse to be worth forbidding; I'm not
proposing declaring old code non-free because it doesn't use techniques
which were not even invented then.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour?
⠈⠳⣄

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Adam Borowski]

On Wed, Jul 24, 2019 at 09:20:07AM -0400, Tiago Bortoletto Vaz wrote:
> On Wed, Jul 24, 2019 at 09:01:34PM +0900, Norbert Preining wrote:
> > (Or, heretic voice, maybe because it is easier to
> > throw people out when everything is standardized?)
> 
> Norbert, it's not the first time in recent emails that you insinuate,
> semi-jokingly, that Debian might "throw people out" for whatever reasons
> you like to think. I just wanted to point out here that this is not
> true in Debian.

Could you at least check whom are you talking about first, please?  Because
at this point your insinuation that Norbert is "joking" is disgusting.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven big-ass trumpets are playing in the
⠈⠳⣄ sky.  Your cat demands food.  The priority should be obvious...

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Harlan Lieberman-Berg]

On Wed, Jul 24, 2019 at 8:56 PM Holger Levsen  wrote:
> On Thu, Jul 25, 2019 at 01:35:59AM +0200, Thomas Goirand wrote:
> > tl;dr: Shall we standardize on 3 layouts? Or simply not vote on this?
> no, its too early to standardize on layouts.

And whether or not it is time (I find myself agreeing with Holger that
it is not), I'm unconvinced that a GR is the correct mechanism for
implementing what feels to me much more like a debian-policy proposal
and revision.

-- 
Harlan Lieberman-Berg
~hlieberman

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Holger Levsen]

On Thu, Jul 25, 2019 at 01:35:59AM +0200, Thomas Goirand wrote:
> 
> tl;dr: Shall we standardize on 3 layouts? Or simply not vote on this?
 
no, its too early to standardize on layouts.


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Thomas Goirand]

On 7/23/19 7:31 PM, Thomas Goirand wrote:
> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
> packaging.
> 
> 2- Mandating using the "gbp patches unapplied" layout for Git, as this
> seems to be the most popular layout, and that we need some kind of
> consistency.
> 
> 3- Mandating using Salsa as a Git repository.

Hi everyone!

After reading the thread, and discussing it during Debconf, I can see
clearly that point 1- doesn't seem controversial, and looks like widely
accepted, that 3- also looks like possible to pass if we allow the
possibility to use mirroring, but that 2- *is* controversial.


tl;dr: Shall we standardize on 3 layouts? Or simply not vote on this?

I still believe that standardizing on Git layouts is important, though
maybe the timing for imposing one or another isn't appropriate,
especially considering that it looks like a lot of people are strongly
unsatisfied with our way to manage upstream patches, using Quilt or
otherwise.

As a consequence, I am withdrawing the proposal to mandate using the
"patches unapplied" layout, because it will frustrate a large amount of
people in our community. Though would it seem sensible to everyone if we
agree on 3 layouts, documented let's say in debian/control with a new
VcsGitLayout or something similar (please suggest a better way to
document this if this exists)? For example, if we had:

VcsLayout: patches-unapplied
or
VcsLayout: patches-applied
or
VcsLayout: debian-folder-only

will that cover enough cases? Is this even a good idea? Let's stay as
open to suggestions as possible in this thread. :)

Also, I've read about workflows, when we're really talking about layout.
Please remove "gbp" out of this discussion, it's irrelevant. I know it's
hard to focus because the layout are directly driving the workflows, but
let's please try!

Finally, is there here a consensus that we should simply not vote on
this at all? Possibly, this also could be a good outcome, I'm not sure
about this yet, and I'm looking forward reading answers on this.


Last, you've probably noticed that I haven't proposed a text for this
GR. This is on purpose, as I want to give it a few weeks for the
conversation to drive the way to write this text. Maybe the whole
summer, so we can vote in September. I've decided to open this
discussion so we can have face-to-face conversation at Debconf, but I
also keep in mind that some of us are probably in holidays.

I'm also still seeking for volunteers to help me write this GR text once
we have finished discussing all of this, and reading everyone's opinion.

Cheers,

Thomas Goirand (zigo)

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Thomas Goirand]

On 7/24/19 6:31 AM, Norbert Preining wrote:
> So be it, but don't put *your* bothering onto others. I am bothered by a
> lot of things, too, and I don't ask you to be bothered the same way.

Even if you dismiss Github, replace it by $foo, and explain to me why I
should register there because you call it $home? Do you expect your
peers in Debian to register as many accounts as there's Git-aaS
platforms in this world?

Look what's been done on other distributions. Nobody else does like us,
because it simply doesn't make sense at all. It's currently a huge mess.
My suggestion is to fix it, once and for all.

Thomas

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Scott Kitterman]

On July 24, 2019 1:16:37 PM UTC, Vincent Bernat  wrote:
> ❦ 24 juillet 2019 12:23 +00, Scott Kitterman :
>
>> This entire discussion feels to me like a small group of developers
>> trying to tell the rest of us "my way or the highway". We are
>> perfectly capable of phasing out obsolete workflows without a hammer
>> like a GR (remember dpatch).
>
>Without a GR, the outcome is decided by a shouting contest. A GR seeems
>great to know if people are a majority or not.

50% + 1 of developers mandating details like this to 50% - 1 of developers is a 
horrible way to solve problems like this.

If you want people to do things a certain way, have it solve problems that 
cause people to decide they want to use it.  Once you get rough consensus on 
the new way, change policy.

Scott K

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Florian Weimer]

* Bastian Blank:

> On Wed, Jul 24, 2019 at 01:46:36AM +0200, Thomas Goirand wrote:
>> On 7/23/19 11:59 PM, Adam Borowski wrote:
>> > Big fat enormous NO!  gbp is a workaround for the biggest evil in our
>> > packaging: quilt.  Watching pro-git-only talks on the Debconf, I got the
>> > impression that if we dropped the VCS-in-VCS approach, there'd be no need
>> > for most of that complexity.
>> How do you track what you've applied in Debian, and the status of your
>> patch upstream? With DEP3 patch headers in d/patches, we track this easily.
>
> git cherry-pick to get new changes. git diff to get all changes, git log
> to list changes.  You just need to know the branch point.
 
I expect you'd need some more tool support to find backports that did
not properly converge after an upstream merge (that is, importing a
new .orig.tar.gz in the current model), so that you can be aware and
remove the lingering difference.  For partially diverging trees, “git
diff” might be a bit too much.  However, I do think that such tooling
will be far simpler and more deterministic than any two-way Git
importer (having written one of those for RPM spec files, complete
with LCS-based editing of Patch:/%patch directives).

But isn't a GR a bit premature?  I would have expected something to
build directly from salsa.debian.org first—like how Fedora builds from
Git repositories on src.fedoraproject.org.  I'd hope for something
without VCS-in-VCS, but even if you prefer that, but build-from-salsa
applies to any approach which mandates a centralized Git (in addition
to the already-centralized archive).

(I really hate VCS-in-VCS, although I know it primarily from a
non-Debian context these days.)

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Bastian Blank]

On Tue, Jul 23, 2019 at 11:59:59PM +0200, Adam Borowski wrote:
> Big fat enormous NO!  gbp is a workaround for the biggest evil in our
> packaging: quilt.  Watching pro-git-only talks on the Debconf, I got the
> impression that if we dropped the VCS-in-VCS approach, there'd be no need
> for most of that complexity.

gbp is nasty stuff, yes.

Years ago I made plans to make good use of the "3.0 (custom)" source
format by writing one large patch into the finished source package.  It
would just work with non-linear history by simply diffing the branch
point and the head.

What is also missing: merge friendly changelog management.

> And, a flat tarball like .orig is no longer a preferred form for
> modification.  Do you remember the brouchacha in 2011 when Red Hat released
> their kernel sources that way?

It was never.  A tarball is a container of files.  The files inside are
the perferred form of modification.

Regards,
Bastian

-- 
It would be illogical to assume that all conditions remain stable.
-- Spock, "The Enterprise Incident", stardate 5027.3

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Bastian Blank]

On Wed, Jul 24, 2019 at 01:46:36AM +0200, Thomas Goirand wrote:
> On 7/23/19 11:59 PM, Adam Borowski wrote:
> > Big fat enormous NO!  gbp is a workaround for the biggest evil in our
> > packaging: quilt.  Watching pro-git-only talks on the Debconf, I got the
> > impression that if we dropped the VCS-in-VCS approach, there'd be no need
> > for most of that complexity.
> How do you track what you've applied in Debian, and the status of your
> patch upstream? With DEP3 patch headers in d/patches, we track this easily.

git cherry-pick to get new changes. git diff to get all changes, git log
to list changes.  You just need to know the branch point.

And nothing forces you not to use DEP3 or something similar in git.  Or
you add a file to that commit with information you need.

Bastian

-- 
"... freedom ... is a worship word..."
"It is our worship word too."
-- Cloud William and Kirk, "The Omega Glory", stardate unknown

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Steffen Möller]

On 24.07.19 17:38, Fabien Givors wrote:
> Le 24/07/2019 à 15:16, Vincent Bernat a écrit :
>> Without a GR, the outcome is decided by a shouting contest. A GR seeems
>> great to know if people are a majority or not.
> A GR is not just a poll.

Yup. I personally see little chance this goes through. To have polls,
among DDs and our users, seems like a good idea, though.

Best,

Steffen

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Fabien Givors]

Le 24/07/2019 à 15:16, Vincent Bernat a écrit :
> Without a GR, the outcome is decided by a shouting contest. A GR seeems
> great to know if people are a majority or not.

A GR is not just a poll.

Consider the following two questions:
i) Which is the recommended workflow among X, Y, Z?
ii) Do I accept, whatever the result of i), to make it mandatory for all
submitted packages?

I'm not sure most would agree to ii) unless they support the option
chosen in i)

What if the chosen standard is far from perfect?
It's been said that the vcs² approach of gbp+quilt is more of a
workaround than a well designed one. And there may be other problems.

How will we be able to make (on even seek) progress if the workflow
requirements are strictly defined?

While the positive outcomes of having such a standard are clear, I think
it should first come as a strong recommendation: the "right way" of
doing packaging in most situations, along with a clear documentation and
a toolchain working out-of-the-box and handling the different use-cases.

If it's the "painless way", it will become a standard even without a GR.

-- 
captnfab

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Ondřej Surý]

> Do you ask me to increase my work load to at least 300% only because of some
> standardization procedure for the minuscule chance that I am suddenly
> abducted by aliens?

No, it’s not about being abducted by the aliens, but there are other more 
realistic factors
that might get any developer to stop contributing. I find it useless to list 
them all just
to prevent you from strawmanning.

> (Or, heretic voice, maybe because it is easier to
> throw people out when everything is standardized?)

Anyway, I am really really tired of your whining in just every message you send,
so I am just blacklisting you.

Ondrej
--
Ondřej Surý
ond...@sury.org

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Tiago Bortoletto Vaz]

On Wed, Jul 24, 2019 at 09:01:34PM +0900, Norbert Preining wrote:
> On Wed, 24 Jul 2019, Ondřej Surý wrote:
> > > so, why isn't it enough to recommend those things?
> > 
> > Because you are not the only developer in the whole world?
> > And when you disappear or just don’t have a time and somebody
> > else needs to fix your packages, then it’s a heap of unnecessary
> > trouble to go through because of someones “personal” preferences.
> 
> Sorry, I spent about 15 years packaging TeX and friends - and I spend
> most of my Debian time with that.
> 
> Do you ask me to increase my work load to at least 300% only because of some
> standardization procedure for the minuscule chance that I am suddenly
> abducted by aliens? (Or, heretic voice, maybe because it is easier to
> throw people out when everything is standardized?)

Norbert, it's not the first time in recent emails that you insinuate,
semi-jokingly, that Debian might "throw people out" for whatever reasons
you like to think. I just wanted to point out here that this is not
true in Debian. And I do this because I don't want people to feel
themselves discouraged of speaking out in the project.

That exhausting process has hurt everybody involved, and has finished
with appologies from both sides after so much pain. And I just can't
believe that we didn't learn anything from it after all.

Bests,

-- 
tiago

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Vincent Bernat]

 ❦ 24 juillet 2019 12:23 +00, Scott Kitterman :

> This entire discussion feels to me like a small group of developers
> trying to tell the rest of us "my way or the highway". We are
> perfectly capable of phasing out obsolete workflows without a hammer
> like a GR (remember dpatch).

Without a GR, the outcome is decided by a shouting contest. A GR seeems
great to know if people are a majority or not.
-- 
Don't sacrifice clarity for small gains in "efficiency".
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Scott Kitterman]

On July 24, 2019 10:43:57 AM UTC, Phil Morrell  wrote:
>On Wed, Jul 24, 2019 at 07:34:02PM +1000, Alexander Zangerl wrote:
>> i detest unwarranted, imposed, uniformity. i *love* consistency. we
>have
>> had consistency in the distribution for ages. we don't need uniform
>> workflows.
>
>It's not (always) about mandating workflows, see Ian's careful
>distinction in the GitPackagingSurvey between sharing format and
>workflow. Your previous mail said:
>
>> as long as the resulting package aupload conforms to the specs i see
>no
>
>I believe this GR is about moving the needle on what those specs say -
>that a source tarball is no longer enough to represent the "preferred
>form of modification" for debian developers (to reference another
>thread).  **If** it's decided that a debian package must have a git
>representation hosted on salsa as a service to users, then yes that may
>restrict your workflow freedom.

Since use of a public VCS isn't universal among free software projects, the 
implication is that one could take a non-free upstream tarball, dump it into 
git on salsa and magically make it free.  I think this is a ridiculous concept.

>I hope it wouldn't go as far as requiring that you literally use
>git-buildpackage itself, but it might say that in non-exceptional
>cases,
>tag2upload must replace dput. That's a long way off, but yes you would
>end up having to adapt your workflow slightly to meet the new spec.

I've been a Debian contributor for over a decade.  I've never built a package 
for upload from anything other than dpkg-buildpackage.  I've used gbp (as well 
as git-dpm and doing it manually) for patch management.

This entire discussion feels to me like a small group of developers trying to 
tell the rest of us "my way or the highway".  We are perfectly capable of 
phasing out obsolete workflows without a hammer like a GR (remember dpatch).

I probably have better things to do with my time than learning from scratch how 
to contribute to Debian.

Scott K

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Norbert Preining]

On Wed, 24 Jul 2019, Ondřej Surý wrote:
> > so, why isn't it enough to recommend those things?
> 
> Because you are not the only developer in the whole world?
> And when you disappear or just don’t have a time and somebody
> else needs to fix your packages, then it’s a heap of unnecessary
> trouble to go through because of someones “personal” preferences.

Sorry, I spent about 15 years packaging TeX and friends - and I spend
most of my Debian time with that.

Do you ask me to increase my work load to at least 300% only because of some
standardization procedure for the minuscule chance that I am suddenly
abducted by aliens? (Or, heretic voice, maybe because it is easier to
throw people out when everything is standardized?)

Why don't you simply trust those who are responsible for packages that
they know what is the most appropriate way?

Are we now in a state in Debian that Developers are treated as employees
that have to obey and follow the rules, or are we still a group of
self-determined engineers that are able to make our own decisions,
including what packaging is the best/most convinient, with the aim of
building the best distribution?

> Debian is a team effort and it always was, although it sometimes

I strongly disagree  - it is **not** - it is the work of lots
of dedicated individuals, not team work. There are some teams that work
together, but this is not Debian.

> It’s fine to be a different, but when it hinders other’s ability to contribute
> sometimes it’s better to bite the bullet and be nice to your fellow
> Debian Developers by making your packaging accessible.

Again weak. If you want to contribute, unpack the source package and fix
bugs, improve packaging, whatever. Then send patches. The maintainer
will include that in the work flow - you learn how it works, and next
time maybe already do the same.

This is not even the slightest reason NOT to contribute.

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Ondřej Surý]

> so, why isn't it enough to recommend those things?

Because you are not the only developer in the whole world?
And when you disappear or just don’t have a time and somebody
else needs to fix your packages, then it’s a heap of unnecessary
trouble to go through because of someones “personal” preferences.

Debian is a team effort and it always was, although it sometimes
look like a team of zen-buddhists - each walking a different path
and different direction - we do converge to a common goal at the
end.

It’s fine to be a different, but when it hinders other’s ability to contribute
sometimes it’s better to bite the bullet and be nice to your fellow
Debian Developers by making your packaging accessible.

Ondrej
--
Ondřej Surý
ond...@sury.org

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Phil Morrell]

On Wed, Jul 24, 2019 at 07:34:02PM +1000, Alexander Zangerl wrote:
> i detest unwarranted, imposed, uniformity. i *love* consistency. we have
> had consistency in the distribution for ages. we don't need uniform
> workflows.

It's not (always) about mandating workflows, see Ian's careful
distinction in the GitPackagingSurvey between sharing format and
workflow. Your previous mail said:

> as long as the resulting package aupload conforms to the specs i see no

I believe this GR is about moving the needle on what those specs say -
that a source tarball is no longer enough to represent the "preferred
form of modification" for debian developers (to reference another
thread).  **If** it's decided that a debian package must have a git
representation hosted on salsa as a service to users, then yes that may
restrict your workflow freedom.

I hope it wouldn't go as far as requiring that you literally use
git-buildpackage itself, but it might say that in non-exceptional cases,
tag2upload must replace dput. That's a long way off, but yes you would
end up having to adapt your workflow slightly to meet the new spec.

> or do you also plan to insist that your roofing contractor only uses
>  tools and only cuts the rafters with your preferred saw?

To extend the analogy, no, but I would be happy insisting that they
place tiles, not thatch, and that rafters are cut in accordance with
local building regulation. This will incidentally turn away all
thatching contractors and anyone's workflow which relies on e.g. cutting
corners when out of sight.

Ultimately, assume a maintainer, or a whole team of uploaders gets hit
by a bus, how can we specify the definition of a "package" such that
other DDs can quickly and easily take up future maintenance.
--
Phil Morrell (emorrp1)


signature.asc
Description: PGP signature

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Thomas Pircher]

Vincent Bernat wrote:
> While not having any official position in either of these projects, I
> was able to contribute easily to both of them because they use a
> standard workflow: no need to read tons of documentation.

There is some truth in this, but I'm not sure the proposal is directly
addressing this issue.

I'm a Debian user with some experience of packaging in-house
applications, and very small exposure to uploading to Debian. I'm adding
my point of view as a relative newbie for packaging, FWIW.

The New Maintainer's Guide currently presents several different workflows,
with very little guidance on which one to use, therefore this proposal
sounds completely backassward to me: new maintainers are supposed to
learn about several competing workflows and figure out themselves which
one to use *before* building their first package, while experienced
developers are being mandated to use one specific one, even though they
might have valid reasons for using a non-standard one.

How about having one *recommended* workflow, which is well documented and
kept up-to-date, while still allowing experienced developers to adopt
alternatives? Or at least do this in two stages: first get newcomers and
people eager to change on board, and only then, in a second step,
mandate a change in workflow from old dogs who must be forced to learn
new tricks.

Thomas

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Sven Bartscher]

Hi,

Am 23.07.19 um 19:31 schrieb Thomas Goirand:
> So, the topics are:
> 
> [snip]>
> 2- Mandating using the "gbp patches unapplied" layout for Git, as this
> seems to be the most popular layout, and that we need some kind of
> consistency.

Other people have already brought up reasons against this, but I just
wanted to mention that the Haskell Group doesn't use a gbp layout for
all of it's packages. Converting all the packages to gbp would mean a
lot of work for the conversion and would probably result in less
convenient workflows for the team once the conversion is done.

At least from my point of view, I don't see how the benefit of
consistency outweighs the cost of conversion and not being able to
adjust your workflows to your needs.

Regards
Sven



signature.asc
Description: OpenPGP digital signature

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Andrey Rahmatullin]

On Wed, Jul 24, 2019 at 07:34:02PM +1000, Alexander Zangerl wrote:
> >> so, why isn't it enough to recommend those things?
> >Because without uniformity, we make it harder for people to contribute.
> 
> i detest unwarranted, imposed, uniformity. i *love* consistency. we have
> had consistency in the distribution for ages. we don't need uniform
> workflows.
> 
> what good can come from reducing diversity and actively probibiting
> flexiblity? 
Other people can more reliably fix your packages.

> and why do you insist on micromanaging the workflow i've got
> to use?
Because you are not the only one who may work on your packages.

> or do you also plan to insist that your roofing contractor only uses
>  tools and only cuts the rafters with your preferred saw?
This comparison is irrelevant.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Alexander Zangerl]

On Wed, 24 Jul 2019 11:23:07 +0200, Vincent Bernat writes:
>> so, why isn't it enough to recommend those things?
>
>Because without uniformity, we make it harder for people to contribute.

i detest unwarranted, imposed, uniformity. i *love* consistency. we have
had consistency in the distribution for ages. we don't need uniform
workflows.

what good can come from reducing diversity and actively probibiting
flexiblity? and why do you insist on micromanaging the workflow i've got
to use?

i thought we wanted to produce a good distribution, not force
everybody gratuitously to use the same tools.

or do you also plan to insist that your roofing contractor only uses
 tools and only cuts the rafters with your preferred saw?

regards
az


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
"[Perl] isn't a programming language, it's a thousand special
case rules flying in close formation."  -- Peter da Silva


signature.asc
Description: Digital Signature

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Andrey Rahmatullin]

On Wed, Jul 24, 2019 at 02:23:26PM +0500, Andrey Rahmatullin wrote:
> > > If we're not willing to force people to use debhelper, forcing them to 
> > > use git and
> > > salsa seems much more extreme.
> > 
> > +1
> > 
> > let's first, if at all, get the mandatory use of debhelper into policy
> > which is much more important.
> As was recently discussed, we don't want to mandate it, but the
> recommendation was added in 4.4.0.
Sorry, this was specifically about dh(1), I don't remember if the
discussion mentioned mandating debhelper in addition to recommending
dh(1).



-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Andrey Rahmatullin]

On Wed, Jul 24, 2019 at 10:49:05AM +0200, Daniel Baumann wrote:
> > If we're not willing to force people to use debhelper, forcing them to use 
> > git and
> > salsa seems much more extreme.
> 
> +1
> 
> let's first, if at all, get the mandatory use of debhelper into policy
> which is much more important.
As was recently discussed, we don't want to mandate it, but the
recommendation was added in 4.4.0.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Vincent Bernat]

 ❦ 24 juillet 2019 17:07 +10, Alexander Zangerl :

> well, i do exist. i have a few packages that aren't vc'd, and i don't see
> any need to change that. while i don't mind git, but i'd hate to be _forced_
> to use salsa and gbp.
>
> so, why isn't it enough to recommend those things?

Because without uniformity, we make it harder for people to contribute.
I have already mentioned Fedora that provides everything in git with CI
enabled, ability to contribute with pull requests, but that's far the
only proponent. For example, NixOS works this way and they maintain more
packages than us with far fewer people. HomeBrew is another example.
While not having any official position in either of these projects, I
was able to contribute easily to both of them because they use a
standard workflow: no need to read tons of documentation.

Having everything in git would be a first step.
-- 
Grief can take care of itself; but to get the full value of a joy you must
have somebody to divide it with.
-- Mark Twain


signature.asc
Description: PGP signature

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Daniel Baumann]

On 7/24/19 7:29 AM, Harlan Lieberman-Berg wrote:
> If we're not willing to force people to use debhelper, forcing them to use 
> git and
> salsa seems much more extreme.

+1

let's first, if at all, get the mandatory use of debhelper into policy
which is much more important.

Regards,
Daniel

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Philip Hands]

Norbert Preining  writes:

...
> I am personally not upset at all,

On reading back what you wrote, I see that the impression I'd somehow
gained has no basis in fact, so I'm sorry for even suggesting it.

Perhaps it was just the brief flurry of "Reply to every email" behaviour
that set some unconscious flag in me, probably harking back to Joey's
thread-patterns post.

Anyway, it looks like people are speaking up for themselves now, which
is good.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Alexander Wirt]

On Wed, 24 Jul 2019, Alexander Zangerl wrote:

> On Wed, 24 Jul 2019 07:07:51 +0200, Philip Hands writes:
> >You may be responding on behalf of people who turn out not to exist.
> 
> well, i do exist. i have a few packages that aren't vc'd, and i don't see
> any need to change that. while i don't mind git, but i'd hate to be _forced_
> to use salsa and gbp.
> 
> so, why isn't it enough to recommend those things?
> 
> as long as the resulting package aupload conforms to the specs i see no
> need to bring out the big bludgeon of policy to silence the
> minority packagers/old farts whose packages are older than 10y/people who 
> don't like salsa.
I don't think that correlates with being old or experienced. 

Alex



signature.asc
Description: PGP signature

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Alexander Zangerl]

On Wed, 24 Jul 2019 07:07:51 +0200, Philip Hands writes:
>You may be responding on behalf of people who turn out not to exist.

well, i do exist. i have a few packages that aren't vc'd, and i don't see
any need to change that. while i don't mind git, but i'd hate to be _forced_
to use salsa and gbp.

so, why isn't it enough to recommend those things?

as long as the resulting package aupload conforms to the specs i see no
need to bring out the big bludgeon of policy to silence the
minority packagers/old farts whose packages are older than 10y/people who don't 
like salsa.

regards
az


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
Fachbegriffe der Informatik, 99.9%: Lüge. -- Uwe Ohse


signature.asc
Description: Digital Signature

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Norbert Preining]

Hi

> Would it not be worth waiting for them to respond to this issue
> themselves, rather than immediately firing off a series of emails that
> give the impression that you are personally upset about this?

Communication with contributors can be difficult and long delayed,
mostly due to being located in China and often away from personal
device. We have one in our team. The respective packages are still
mentined as old svn, not existing any more.

Do you think they have time and energy to reading this here and comment?

I am personally not upset at all, I just find it not a good idea to
*mandate* things that are very personal development practices.
But if we want to get rid of some developers, well, this is a way ahead
I guess.

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Harlan Lieberman-Berg]

On Tue, Jul 23, 2019 at 1:31 PM Thomas Goirand  wrote:
> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
> packaging.

While I personally don't have a problem with this, I'm not sure how
/necessary/ it is.  Though inconvenient, if we have source-only
uploads as mandatory, we can always do a mass NMU.  Ugly, but
possible.

> 2- Mandating using the "gbp patches unapplied" layout for Git, as this
> seems to be the most popular layout, and that we need some kind of
> consistency.

While this is how most of my packages are, because they're maintained
in teams, I'd not want to see it as policy.  The debcherry workflow is
much easier to work with on so many different levels.  If we're not
willing to force people to use debhelper, forcing them to use git and
salsa seems much more extreme.  In terms of packages that I actively
avoid contributing to, packages using CDBS are way, way higher on my
ick-list than things using svn or mercurial, or even something more
esoteric like pijul or darcs.  Hell, I'll take perforce over CDBS.

-- 
Harlan Lieberman-Berg
~hlieberman

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Philip Hands]

Norbert Preining  writes:

...
> Fine with me, strongly recommend git - anyway, it is already a fact that
> it is the de-facto standard, so this is a non-argument. My argument is
> for those developers who might have other ways/interests.

Would it not be worth waiting for them to respond to this issue
themselves, rather than immediately firing off a series of emails that
give the impression that you are personally upset about this?

You may be responding on behalf of people who turn out not to exist.

Cheers, Phil
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Norbert Preining]

Hi Thomas,

> Then use one?

I do use, but several people I know don't.

> The idea is to be able to use unified tooling. Currently, we can't for
> example easily do a mass-commit on all packages. Or apply a new CI test

How do you want to handle permissions? So there is a super user on salsa
who can commit to any repository there? I would be well at least
slightly surprised to see such changes.

> to all packages. And that's even without considering the entry barrier
> for contributing to the Debian archive. In for example FreeBSD, it's a
> way more obvious how to contribute to /usr/ports. In Debian, it's not.

Fine with me, strongly recommend git - anyway, it is already a fact that
it is the de-facto standard, so this is a non-argument. My argument is
for those developers who might have other ways/interests.

> Maybe you could at least consider moving away from Github, and switch to
> a platform based on free software? For example own gitlab instance. Or

Why? All the data is in the git commits and tags. I don't use anything
else there, in particular not issues etc. 
So what is your concern besides "religious" github hating?

> anything else. I'm really bothered by Github, like a few of us are.

So be it, but don't put *your* bothering onto others. I am bothered by a
lot of things, too, and I don't ask you to be bothered the same way.

Thanks

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Thomas Goirand]

On 7/23/19 11:59 PM, Adam Borowski wrote:
> On Tue, Jul 23, 2019 at 07:31:11PM +0200, Thomas Goirand wrote:
>> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
>> packaging.
> 
> Good.  Especially if we can then drop quilt.
>  
>> 2- Mandating using the "gbp patches unapplied" layout for Git, as this
>> seems to be the most popular layout, and that we need some kind of
>> consistency.
> 
> Big fat enormous NO!  gbp is a workaround for the biggest evil in our
> packaging: quilt.  Watching pro-git-only talks on the Debconf, I got the
> impression that if we dropped the VCS-in-VCS approach, there'd be no need
> for most of that complexity.

How do you track what you've applied in Debian, and the status of your
patch upstream? With DEP3 patch headers in d/patches, we track this easily.

Cheers,

Thomas Goirand (zigo)

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Philip Hands]

Steve McIntyre  writes:

>>3- Mandating using Salsa as a Git repository.
>>
>>I do believe #1 will pass easily, but that it's useless without #2, and
>>there is some kind of uncertainty. For #3, I'm not even sure we should
>>vote for that, I probably even prefer it not to be voted for myself,
>>though what's annoying me is having to pull some packaging from non-free
>>services such as Github, and this would make an end to it.
>
> There are genuinely good reasons for *not* using salsa. If the debian
> packaging is directly included as part of the upstream git repo(s)
> somewhere else, for example. It's a good thing to encourage salsa
> usage (and I agree 100% with that for most things), but let's not
> argue about making things mandatory please.

If the problem one is trying to fix is people keeping the only copy on
some proprietary service (which I think Thomas cited as motivation),
perhaps it would be sufficient to suggest/recommend that people have an
additional repo on salsa, and set up the hooks to ensure that every push
gets immediately bounced onto salsa.

I'd think that most people would have few objections to doing that,
especially since it gives them the reassurance of a backup.

Perhaps all that's really needed here is documentation to point people
at that tells them how to do it easily easily.

Of course there's still the question of how to deal with the metadata
surrounding the repo, that might be stuck inside the proprietary
service, so maybe that's not a complete fix.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Holger Levsen]

On Tue, Jul 23, 2019 at 11:59:59PM +0200, Adam Borowski wrote:
> On Tue, Jul 23, 2019 at 07:31:11PM +0200, Thomas Goirand wrote:
> > 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
> > packaging.
> 
> Good.  Especially if we can then drop quilt.
>  
> > 2- Mandating using the "gbp patches unapplied" layout for Git, as this
> > seems to be the most popular layout, and that we need some kind of
> > consistency.
> 
> Big fat enormous NO!  gbp is a workaround for the biggest evil in our
> packaging: quilt.  Watching pro-git-only talks on the Debconf, I got the
> impression that if we dropped the VCS-in-VCS approach, there'd be no need
> for most of that complexity.
> 
> The vast majority of upstreams already use git, adding 1980's-style patches
> on top of that is like pulling a non-broken car with a horse.
> 
> And, a flat tarball like .orig is no longer a preferred form for
> modification.  Do you remember the brouchacha in 2011 when Red Hat released
> their kernel sources that way?
> 
> I'd say we should drop .orig and _forbid_ gbp.
> 
> > 3- Mandating using Salsa as a Git repository.
> 
> Or perhaps we could have a service mirror official git repos for packages
> hosted elsewhere?

I second kilobyte's amendment. Except the part about dropping .orig,
somewhat sadly.

Put more seriously: #1 I'd agree with, #2 I think is impossible and for
#3 I really like the idea of mirroring them all, https://src.fedoraproject.org
is indeed really cool.


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Adam Borowski]

On Tue, Jul 23, 2019 at 07:31:11PM +0200, Thomas Goirand wrote:
> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
> packaging.

Good.  Especially if we can then drop quilt.
 
> 2- Mandating using the "gbp patches unapplied" layout for Git, as this
> seems to be the most popular layout, and that we need some kind of
> consistency.

Big fat enormous NO!  gbp is a workaround for the biggest evil in our
packaging: quilt.  Watching pro-git-only talks on the Debconf, I got the
impression that if we dropped the VCS-in-VCS approach, there'd be no need
for most of that complexity.

The vast majority of upstreams already use git, adding 1980's-style patches
on top of that is like pulling a non-broken car with a horse.

And, a flat tarball like .orig is no longer a preferred form for
modification.  Do you remember the brouchacha in 2011 when Red Hat released
their kernel sources that way?

I'd say we should drop .orig and _forbid_ gbp.

> 3- Mandating using Salsa as a Git repository.

Or perhaps we could have a service mirror official git repos for packages
hosted elsewhere?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts
⣾⠁⢰⠒⠀⣿⡁ productivity.  You can read it, too, you just need the
⢿⡄⠘⠷⠚⠋⠀ right music while doing so.  I recommend Skepticism
⠈⠳⣄ (funeral doom metal).

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Russ Allbery]

Michael Banck  writes:
> On Tue, Jul 23, 2019 at 07:31:11PM +0200, Thomas Goirand wrote:

>> This probably has been floating around for some time. IMO, enough time
>> so that we start to discuss $subject.

> Why is this a GR and not a policy proposal?

Policy changes require strong consensus, and it's very unlikely that we
have that sort of strong consensus here.

Put another way, Policy is already behind on documenting things that we've
all already agreed about but that need some time and attention to document
properly (stuff like triggers, good practices for systemd units,
multi-arch, and so forth).  For things like this that will be
controversial (see also dropping our support level for alternate init
systems, which comes up periodically), we're going to ask the project to
find some other decision-making process.

For a proposal like this, I think a GR may be the best decision-making
process we have.  (This shouldn't be taken as an opinion either way on
whether this proposal specifically should be adopted.)  If we do want to
change our historic maintainer-driven free-for-all and start mandating
specific tools, that's a sufficiently large *cultural* change in the
process that, unless we can reach some sort of guided consensus like we
did with dh (and I think this is more controversial and is also a much
stronger statement than we arrived at with dh), having everyone vote on it
is probably the right move.

-- 
Russ Allbery (r...@debian.org)   

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Andrey Rahmatullin]

On Tue, Jul 23, 2019 at 04:47:32PM -0300, Michael Banck wrote:
> > This probably has been floating around for some time. IMO, enough time
> > so that we start to discuss $subject.
> 
> Why is this a GR and not a policy proposal?
The policy documents the majority practices, which I think cannot be said
about using Vcs-Git, let alone specific workflows and repo locations.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Michael Banck]

Hi,

On Tue, Jul 23, 2019 at 07:31:11PM +0200, Thomas Goirand wrote:
> This probably has been floating around for some time. IMO, enough time
> so that we start to discuss $subject.

Why is this a GR and not a policy proposal?


Michael

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Ondřej Surý]

> Most other distributions I know about seem to have only the packaging
> information (debian/*) and not the upstream source in their version
> control system.  So more people might be familiar with this; it also
> also makes tree-wide changes to packaging much easier ;-)

Is there a tooling around gbp that can do that?  It would be great if there was.

Ondrej
--
Ondřej Surý
ond...@sury.org

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Ansgar]

Thomas Goirand writes:
> The idea is to be able to use unified tooling. Currently, we can't for
> example easily do a mass-commit on all packages. Or apply a new CI test
> to all packages.

That wouldn't be changed by having all repositories on Salsa.  You would
need to require the same permissions for all packages.

Some packages might even require signing some legal document to
contribute to (unless you NMU them)...

> In for example FreeBSD, it's a way more obvious how to contribute to
> /usr/ports. In Debian, it's not.

Most other distributions I know about seem to have only the packaging
information (debian/*) and not the upstream source in their version
control system.  So more people might be familiar with this; it also
also makes tree-wide changes to packaging much easier ;-)

Ansgar

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Thomas Goirand]

On 7/23/19 8:05 PM, Steve McIntyre wrote:
> There are genuinely good reasons for *not* using salsa. If the debian
> packaging is directly included as part of the upstream git repo(s)
> somewhere else, for example.

I just has a very interesting conversation with Tollef. If you use a
native package, then it's easy to pull for upstream, and for upstream to
pull from you. That's IMO a nice workaround.

> It's a good thing to encourage salsa
> usage (and I agree 100% with that for most things), but let's not
> argue about making things mandatory please.

If we need exceptions, we can take care of them in the GR text, and even
make the rules for such exceptions explicitly fuzzy. However, I believe
this will concerns a very small amount of packages.

Cheers,

Thomas Goirand (zigo)

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Ondřej Surý]

> On 23 Jul 2019, at 15:11, Thomas Goirand  wrote:
> 
> 
> The idea is to be able to use unified tooling. Currently, we can't for
> example easily do a mass-commit on all packages. Or apply a new CI test
> to all packages. And that's even without considering the entry barrier
> for contributing to the Debian archive. In for example FreeBSD, it's a
> way more obvious how to contribute to /usr/ports. In Debian, it's not.

Well, yes, please.  We should have done that years ago.  It’s extremely
bothersome if you need to help fix a other developer/maintainer’s package
and they don’t use DVCS (well, I mean git) and a layout that gbp can work
with smoothly.

I usually end up importing packages into gbp and working from the local
mirror.  But it is bothersome.

Thanks for doing that,
--
Ondřej Surý
ond...@sury.org

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Thomas Goirand]

On 7/23/19 7:55 PM, Norbert Preining wrote:
> Hi
> 
> On Tue, 23 Jul 2019, Thomas Goirand wrote:
>> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
>> packaging.
> 
> I don't see how we can mandate git. What if I do *not* use any vcs at
> all?

Then use one?

> I don't see that mandating git has any reason besides the "appeal to
> popularity", which at least in critical thinking circles is commonly
> seen as fallacy.

The idea is to be able to use unified tooling. Currently, we can't for
example easily do a mass-commit on all packages. Or apply a new CI test
to all packages. And that's even without considering the entry barrier
for contributing to the Debian archive. In for example FreeBSD, it's a
way more obvious how to contribute to /usr/ports. In Debian, it's not.

>> 2- Mandating using the "gbp patches unapplied" layout for Git, as this
>> seems to be the most popular layout, and that we need some kind of
>> consistency.
> 
> Again, this might be a good idea for a recommendation, but mandating
> doesn't make sense.

Same reason as above.

>> 3- Mandating using Salsa as a Git repository.
> 
> No comment on that from my side. I will not move there.

Maybe you could at least consider moving away from Github, and switch to
a platform based on free software? For example own gitlab instance. Or
anything else. I'm really bothered by Github, like a few of us are.

Cheers,

Thomas Goirand (zigo)

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Vincent Bernat]

 ❦ 23 juillet 2019 19:05 +01, Steve McIntyre :

>>3- Mandating using Salsa as a Git repository.
>>
>>I do believe #1 will pass easily, but that it's useless without #2, and
>>there is some kind of uncertainty. For #3, I'm not even sure we should
>>vote for that, I probably even prefer it not to be voted for myself,
>>though what's annoying me is having to pull some packaging from non-free
>>services such as Github, and this would make an end to it.
>
> There are genuinely good reasons for *not* using salsa. If the debian
> packaging is directly included as part of the upstream git repo(s)
> somewhere else, for example. It's a good thing to encourage salsa
> usage (and I agree 100% with that for most things), but let's not
> argue about making things mandatory please.

git being distributed, you can still push to Salsa too. I don't know the
first thing about Fedora, but they have everything in one place [0] and
I can take a look, browse through history, it seems I can contribute
with just a PR and all packages have the CI plugged in.

[0]: https://src.fedoraproject.org/
-- 
Use library functions.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Steve McIntyre]

Hey Thomas!

On Tue, Jul 23, 2019 at 07:31:11PM +0200, Thomas Goirand wrote:
>
>This probably has been floating around for some time. IMO, enough time
>so that we start to discuss $subject.
>
>Before starting any type of text for such a GR, I'd like to hear you
>folks. What are your thougts about all this? Especially, I'd like to
>hear others that would be *AGAINST* such a GR.
>
>I'm not sure yet I really want to start all of this. Sometimes, no GR is
>better than a GR. If the discussions we will have here leads me to
>believe there's no chance for the GR to pass, I probably wont initiate
>it. But at least, I would like the discussion to start.
>
>So, the topics are:
>
>1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
>packaging.

While this may seem like a no-brainer. there really are things that
git doesn't do well. Really large binary files do not work well in a
git repo - talk to the games team, for example.

>2- Mandating using the "gbp patches unapplied" layout for Git, as this
>seems to be the most popular layout, and that we need some kind of
>consistency.

I think there's far more variation here than you think.

>3- Mandating using Salsa as a Git repository.
>
>I do believe #1 will pass easily, but that it's useless without #2, and
>there is some kind of uncertainty. For #3, I'm not even sure we should
>vote for that, I probably even prefer it not to be voted for myself,
>though what's annoying me is having to pull some packaging from non-free
>services such as Github, and this would make an end to it.

There are genuinely good reasons for *not* using salsa. If the debian
packaging is directly included as part of the upstream git repo(s)
somewhere else, for example. It's a good thing to encourage salsa
usage (and I agree 100% with that for most things), but let's not
argue about making things mandatory please.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Managing a volunteer open source project is a lot like herding
 kittens, except the kittens randomly appear and disappear because they
 have day jobs." -- Matt Mackall

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Norbert Preining]

On Wed, 24 Jul 2019, Norbert Preining wrote:
> > 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
> > packaging.

I forgot to add. If you ever want to go there, you also have to add
mandate that the maintainer pushes the most recent versions
to the VcsGit specified repository.
git is as everyone knows completely distributed, so using it locally
without a remote is viable.

Even till now I know too many packages where the released versions and
the one in the VcsGit are widely apart. Do you want mandating certain
push behaviour of developers?

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Norbert Preining]

Hi

On Tue, 23 Jul 2019, Thomas Goirand wrote:
> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
> packaging.

I don't see how we can mandate git. What if I do *not* use any vcs at
all? And I know enough projects that run on svn, hg, and other vcs.
I don't see that mandating git has any reason besides the "appeal to
popularity", which at least in critical thinking circles is commonly
seen as fallacy.

> 2- Mandating using the "gbp patches unapplied" layout for Git, as this
> seems to be the most popular layout, and that we need some kind of
> consistency.

Again, this might be a good idea for a recommendation, but mandating
doesn't make sense.

> 3- Mandating using Salsa as a Git repository.

No comment on that from my side. I will not move there.

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Thomas Goirand]

Hi there!

This probably has been floating around for some time. IMO, enough time
so that we start to discuss $subject.

Before starting any type of text for such a GR, I'd like to hear you
folks. What are your thougts about all this? Especially, I'd like to
hear others that would be *AGAINST* such a GR.

I'm not sure yet I really want to start all of this. Sometimes, no GR is
better than a GR. If the discussions we will have here leads me to
believe there's no chance for the GR to pass, I probably wont initiate
it. But at least, I would like the discussion to start.

So, the topics are:

1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
packaging.

2- Mandating using the "gbp patches unapplied" layout for Git, as this
seems to be the most popular layout, and that we need some kind of
consistency.

3- Mandating using Salsa as a Git repository.

I do believe #1 will pass easily, but that it's useless without #2, and
there is some kind of uncertainty. For #3, I'm not even sure we should
vote for that, I probably even prefer it not to be voted for myself,
though what's annoying me is having to pull some packaging from non-free
services such as Github, and this would make an end to it.

Please do devide your replies clearly on the 3 topics. If you see other
topics that should be discussed, please identify them clearly as well.

For those not convinced yet on the utility of such a GR, just think
about a few months/years from now, where we will be 100% sure that
absolutely all packages will be hosted on Salsa (or another system we
decide to migrate to) with the same Git layout, and how easy it will be
(for example) to add some kind of CI/CD for all packages.

Cheers,

Thomas Goirand (zigo)