Re: [OpenWrt-Devel] SVN to GIT transition / paid patch-checking

[bkil]

Hello,

Sorry for my late input.

I'd been considering starting a funded, but non-profit fork with close
upstream collaboration just for the above reasons and for reasons even
beyond that. I'm delighted that others came to a similar conclusion.

Start seems probable (early?) next year. I welcome any input relating
to this topic.

Regards,
bkil

On Tue, Oct 13, 2015 at 5:10 PM, Bastian Bittorf  wrote:
> * Daniel Golle  [13.10.2015 16:53]:
>> If you want an industry-driven fork, go ahead. But don't force that
>> model upon an existing community without understanding how major parts
>> of that said community is operating.
>
> What I see since a long time, is that there is simply not
> enough manpower for reviewing patches and "simple" maintainance
> work (trac, buildbots) and this more and more leads to an unhappy
> community and overloaded devs.
>
> commercial pressure is'nt good, i agree - but maybe there is
> a way to have at least 1 fulltime or 2 parttime devs.
>
> bye, bastian
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-13 10:45, Roman Yeryomin wrote:
> On 13 October 2015 at 10:50, Bruno Randolf  wrote:
>> On 10/12/2015 10:53 PM, Felix Fietkau wrote:
 git describe

 r-35387-g83c5a41

 If you prefer, cut the last part and get "r-35387".

 Looks familiar? Now you even have real linear numbering in each branch,
 without the gaps you get when committing to different branches in SVN +
 the unique hash. Need to look up the commit? Use the hash (g83c5a41).

 Of course "r" is just an example to show the familiarity with SVN
 revisions, you could choose whatever seems fit, for example at this
 moment it would make sense to tag the moment when 15.05 was branched off
 from trunk as "dd", then you'd get "dd-number-hash" in trunk and
 "15.05-66-g66620f5" in the 15.05 branch (you actually do, just need to
 use "git describe --tags" because the tag was not created with -a).
>>>
>>> That looks quite interesting. The issue I see with that is if somebody
>>> adds a local commit on top and builds the tree, the number behind 'r' is
>>> misleading and the hash is useless.
>>
>> Right, I see, the ambiguous numbering with local commits may be a weak
>> point. But then, if you don't find the hash in the OpenWRT git, you also
>> know that it's not a clean copy of trunk and that's also valuable
>> information. People should report bugs from clean trunk, not containing
>> random, unknown, additional commits.
>>
> 
> and then, again, if a user is able to commit something usually that
> means he is able to understand that reporting his local changes
> doesn't make sense.
People report bugs all the time, and if I'm lucky enough to have a bug
report containing revision information, I want to maximize the
likelihood of that revision information being useful (even if there are
some local commits on top of that).
Any assumptions about users thinking carefully if the revision info that
they're posting is meaningful enough is flawed. People usually just post
whatever is in the banner file.
Often bug reports can be anonymous, or reporters just don't respond
after posting the ticket. I don't want to compromise any remaining
usefulness of such tickets.

> Though, I still think that appropriate, meaningful tags will be a
> better option to just r (which would be just svn legacy).
> Not sure but probably both options could be used in parallel.
A fake 'r' value is useless if I can't use it to look up the
corresponding OpenWrt commit.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Javier Domingo Cansino]

>
> People report bugs all the time, and if I'm lucky enough to have a bug
> report containing revision information, I want to maximize the
> likelihood of that revision information being useful (even if there are
> some local commits on top of that).
> Any assumptions about users thinking carefully if the revision info that
> they're posting is meaningful enough is flawed. People usually just post
> whatever is in the banner file.
> Often bug reports can be anonymous, or reporters just don't respond
> after posting the ticket. I don't want to compromise any remaining
> usefulness of such tickets.
>
> > Though, I still think that appropriate, meaningful tags will be a
> > better option to just r (which would be just svn legacy).
> > Not sure but probably both options could be used in parallel.
> A fake 'r' value is useless if I can't use it to look up the
> corresponding OpenWrt commit.
>

Supposing we are able to trace the exact base and the modifications, what
would be left?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Roman Yeryomin]

On 14 October 2015 at 10:10, Felix Fietkau  wrote:
> On 2015-10-13 10:45, Roman Yeryomin wrote:
>> On 13 October 2015 at 10:50, Bruno Randolf  wrote:
>>> On 10/12/2015 10:53 PM, Felix Fietkau wrote:
> git describe
>
> r-35387-g83c5a41
>
> If you prefer, cut the last part and get "r-35387".
>
> Looks familiar? Now you even have real linear numbering in each branch,
> without the gaps you get when committing to different branches in SVN +
> the unique hash. Need to look up the commit? Use the hash (g83c5a41).
>
> Of course "r" is just an example to show the familiarity with SVN
> revisions, you could choose whatever seems fit, for example at this
> moment it would make sense to tag the moment when 15.05 was branched off
> from trunk as "dd", then you'd get "dd-number-hash" in trunk and
> "15.05-66-g66620f5" in the 15.05 branch (you actually do, just need to
> use "git describe --tags" because the tag was not created with -a).

 That looks quite interesting. The issue I see with that is if somebody
 adds a local commit on top and builds the tree, the number behind 'r' is
 misleading and the hash is useless.
>>>
>>> Right, I see, the ambiguous numbering with local commits may be a weak
>>> point. But then, if you don't find the hash in the OpenWRT git, you also
>>> know that it's not a clean copy of trunk and that's also valuable
>>> information. People should report bugs from clean trunk, not containing
>>> random, unknown, additional commits.
>>>
>>
>> and then, again, if a user is able to commit something usually that
>> means he is able to understand that reporting his local changes
>> doesn't make sense.
> People report bugs all the time, and if I'm lucky enough to have a bug
> report containing revision information, I want to maximize the
> likelihood of that revision information being useful (even if there are
> some local commits on top of that).
> Any assumptions about users thinking carefully if the revision info that
> they're posting is meaningful enough is flawed. People usually just post
> whatever is in the banner file.
> Often bug reports can be anonymous, or reporters just don't respond
> after posting the ticket. I don't want to compromise any remaining
> usefulness of such tickets.

git describe origin is solving all your worries
Then you can add his local commit hash if there are any and dirty flag
to indicate if uncommited changes are present.
Much better than svn revision in all ways.

>> Though, I still think that appropriate, meaningful tags will be a
>> better option to just r (which would be just svn legacy).
>> Not sure but probably both options could be used in parallel.
> A fake 'r' value is useless if I can't use it to look up the
> corresponding OpenWrt commit.

see above

Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Roman Yeryomin]

On 13 October 2015 at 10:50, Bruno Randolf  wrote:
> On 10/12/2015 10:53 PM, Felix Fietkau wrote:
>>> git describe
>>>
>>> r-35387-g83c5a41
>>>
>>> If you prefer, cut the last part and get "r-35387".
>>>
>>> Looks familiar? Now you even have real linear numbering in each branch,
>>> without the gaps you get when committing to different branches in SVN +
>>> the unique hash. Need to look up the commit? Use the hash (g83c5a41).
>>>
>>> Of course "r" is just an example to show the familiarity with SVN
>>> revisions, you could choose whatever seems fit, for example at this
>>> moment it would make sense to tag the moment when 15.05 was branched off
>>> from trunk as "dd", then you'd get "dd-number-hash" in trunk and
>>> "15.05-66-g66620f5" in the 15.05 branch (you actually do, just need to
>>> use "git describe --tags" because the tag was not created with -a).
>>
>> That looks quite interesting. The issue I see with that is if somebody
>> adds a local commit on top and builds the tree, the number behind 'r' is
>> misleading and the hash is useless.
>
> Right, I see, the ambiguous numbering with local commits may be a weak
> point. But then, if you don't find the hash in the OpenWRT git, you also
> know that it's not a clean copy of trunk and that's also valuable
> information. People should report bugs from clean trunk, not containing
> random, unknown, additional commits.
>

and then, again, if a user is able to commit something usually that
means he is able to understand that reporting his local changes
doesn't make sense.
Though, I still think that appropriate, meaningful tags will be a
better option to just r (which would be just svn legacy).
Not sure but probably both options could be used in parallel.

Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Roman Yeryomin]

On 13 October 2015 at 00:18, Bruno Randolf  wrote:
> On 10/12/2015 03:22 PM, Felix Fietkau wrote:
 When using tags as a starting point (via git describe), somebody has to
 create those tags, which is cumbersome (and would mean adding lots of
 useless ones).
>>>
>>> What's cumbersome? And why would you have to create useless tags?
>>>
>> Many people follow current trunk, and we need to have precise version
>> information for that when they report a bug. We don't want to regularly
>> tag stuff just to keep reported version information up to date.
>
> You don't need to. Try this in your OpenWRT trunk git repo:
>
> git tag -a r 753606a51c979440e10771f0d11494b7b7c1eac2
>
> (Tagging the very first commit with "r".)
>
> Now do:
>
> git describe
>
> r-35387-g83c5a41
>

Bruno, +100500!
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Bruno Randolf]

On 10/12/2015 10:53 PM, Felix Fietkau wrote:
>> git describe
>>
>> r-35387-g83c5a41
>>
>> If you prefer, cut the last part and get "r-35387".
>>
>> Looks familiar? Now you even have real linear numbering in each branch,
>> without the gaps you get when committing to different branches in SVN +
>> the unique hash. Need to look up the commit? Use the hash (g83c5a41).
>>
>> Of course "r" is just an example to show the familiarity with SVN
>> revisions, you could choose whatever seems fit, for example at this
>> moment it would make sense to tag the moment when 15.05 was branched off
>> from trunk as "dd", then you'd get "dd-number-hash" in trunk and
>> "15.05-66-g66620f5" in the 15.05 branch (you actually do, just need to
>> use "git describe --tags" because the tag was not created with -a).
>
> That looks quite interesting. The issue I see with that is if somebody
> adds a local commit on top and builds the tree, the number behind 'r' is
> misleading and the hash is useless.

Right, I see, the ambiguous numbering with local commits may be a weak
point. But then, if you don't find the hash in the OpenWRT git, you also
know that it's not a clean copy of trunk and that's also valuable
information. People should report bugs from clean trunk, not containing
random, unknown, additional commits.

bruno
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Roman Yeryomin]

On 12 October 2015 at 22:21, Jonathan Bennett  wrote:
>
>
> On Mon, Oct 12, 2015 at 2:11 PM David Lang  wrote:
>>
>> On Mon, 12 Oct 2015, Felix Fietkau wrote:
>>
>> > On 2015-10-12 16:11, Roman Yeryomin wrote:
>> >> On 12 October 2015 at 16:34, Felix Fietkau  wrote:
>> >>> On 2015-10-12 15:09, Javier Domingo Cansino wrote:
>>  Right now, the revision number (r) is really useful to
>>  figure
>>  out what particular openwrt version is being used, when people
>>  report
>>  bugs. The commit hash cannot be used as a replacement, since it
>>  might be
>>  one that isn't present in the official repo.
>>  When using tags as a starting point (via git describe), somebody
>>  has to
>>  create those tags, which is cumbersome (and would mean adding
>>  lots of
>>  useless ones).
>> 
>>  The tags would be the major versions and RCs. I don't believe other
>>  tags
>>  should be used.
>> 
>>  Apart from that, I understand that if someone cloned the SVN repo
>>  (full
>>  svn history), created it's own server, and developed on top of a
>>  given
>>  revision X, the same problem would arise.
>> >>> I haven't seen a single instance of somebody doing this, and in my
>> >>> opinion it would be kind of stupid anyway :)
>> >>> We don't even advertise the SVN server URL to users anymore for a
>> >>> reason.
>> >>>
>> >>
>> >> IMO git describe --dirty would work perfectly. You would see a short
>> >> hash and if user modified it or not.
>> > If the user made a local commit, the short hash becomes useless.
>>
>> if the user does a SVN checkout and then modifies things, the r is
>> also
>> not valid (although it does give you an idea where things branched)
>>
>> David Lang
>
> His point is that users don't ever do an SVN checkout. Because the r number
> is baked into the image, it's a really easy and obvious way for an end user
> to report the revision in a bug report.  I can see the advantage in this.
> If we are to move to git, we would want some way to preserve this feature,
> that is a super easy way for a user to report the revision.  We could bake
> the short hash into the image, but this would not be useful if any commits
> were added locally, whereas the r number would still show some useful
> information.
>
> Would it be possible to track the revision number in an automated way even
> in a git repo?  So store the r number, and automatically increment on
> commits.  Not sure if that's an option, but it seems like it might address
> the problem.
>

If a user is smart enough to commit something locally then he knows
what he is doing and is smart enough to report the changes he made.
It's so simple.

Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition / paid patch-checking

[Sorin Burjan]

Hello Kaloz,

is there any initiative to create a non-profit organization ?

Regards,
Sorin B.

On Tue, Oct 13, 2015 at 1:44 PM, Imre Kaloz  wrote:

> On Tue, 13 Oct 2015 12:33:35 +0200, Bastian Bittorf
>  wrote:
>
> 
>
> It should be easy possible to get funding from all the companies which
>> work with OpenWrt. Is this in option?
>>
>
> Not until we have a nonprofit organization as companies can't have tax
> deduction in exchange.. This is pretty much the main issue people from said
> companies brought up at the summit as well.
>
>
> Imre
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition / paid patch-checking

[Imre Kaloz]

On Tue, 13 Oct 2015 12:33:35 +0200, Bastian Bittorf
 wrote:




It should be easy possible to get funding from all the companies which
work with OpenWrt. Is this in option?


Not until we have a nonprofit organization as companies can't have tax  
deduction in exchange.. This is pretty much the main issue people from  
said companies brought up at the summit as well.



Imre
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition / paid patch-checking

[Imre Kaloz]

On Tue, 13 Oct 2015 12:46:00 +0200, Sorin Burjan   
wrote:



Hello Kaloz,

is there any initiative to create a non-profit organization ?


We're looking into this as well other options ;)


Imre
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition / paid patch-checking

[edgar . soldin]

On 13.10.2015 12:44, Imre Kaloz wrote:
> On Tue, 13 Oct 2015 12:33:35 +0200, Bastian Bittorf
>  wrote:
> 
> 
> 
>> It should be easy possible to get funding from all the companies which
>> work with OpenWrt. Is this in option?
> 
> Not until we have a nonprofit organization as companies can't have tax 
> deduction in exchange.. This is pretty much the main issue people from said 
> companies brought up at the summit as well.
> 
> 

how about said companies simply employ(part time even)/pay core devs for 
working on openwrt? 

if they really want to give back tax deductability shouldn't be an issue. there 
are costs of business that are not deductible. why should openwrt people be 
forced into forming/maintaining organizational infrastructure, when they could 
spend that time enhancing openwrt instead.

..ede
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition / paid patch-checking

[Nemesis]

As far as I remember, there's no initiative going on, but the issue was
brought up at the summit by different speakers.

There was also a quick poll:

1. Kathy Giori asked the attendees to raise their hand if they backed
the idea of an OpenWRT foundation
I would say half of the presents raised their hands (I did not because
I'm not involved so much in OpenWRT and I don't feel entitled to take sides)

2. Kathy asked the attendees to raise their hand if they opposed the
idea of an OpenWRT foundation
I think there were almost no raised hands or not at all

Federico


On 10/13/2015 12:46 PM, Sorin Burjan wrote:
> Hello Kaloz,
>
> is there any initiative to create a non-profit organization ?
>
> Regards,
> Sorin B.
>
> On Tue, Oct 13, 2015 at 1:44 PM, Imre Kaloz  > wrote:
>
> On Tue, 13 Oct 2015 12:33:35 +0200, Bastian Bittorf
> > wrote:
>
> 
>
> It should be easy possible to get funding from all the
> companies which
> work with OpenWrt. Is this in option?
>
>
> Not until we have a nonprofit organization as companies can't have
> tax deduction in exchange.. This is pretty much the main issue
> people from said companies brought up at the summit as well.
>
>
> Imre
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> 
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
>
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition / paid patch-checking

[Bastian Bittorf]

* Nemesis  [12.10.2015 12:17]:
> The Django Framework moved from SVN to github in 2012but they kept their
> own bug tracker (which they redesigned with some funding to make it more
> usable): https://code.djangoproject.com/
> 
> I think they're a good example of an open source community which went
> through the process of improving the way people can join the community
> and contribute, they also raise funds to pay for hard tasks like
> redesigning the website, organizing sprints, periodically hire a
> "fellow" which reviews (accepts/closes and occasionally fixes) tickets
> and so on.
> Since they started doing this django has improved massively.

I think that is a good point. The active OpenWrt-Team seems
to consist of 3-4 people. Has somebody of them considered to work
fulltime for the project? This way the always growing Patchwork (~100
open patches) and Ticketsystem (>3000 open Tickets) would benefit.

It should be easy possible to get funding from all the companies which
work with OpenWrt. Is this in option?

bye, bastian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition / paid patch-checking

[Daniel Golle]

Hi!

On Tue, Oct 13, 2015 at 01:22:14PM +0200, Emmanuel Deloget wrote:
> On Tue, Oct 13, 2015 at 1:04 PM, Nemesis  wrote:
> > As far as I remember, there's no initiative going on, but the issue was 
> > brought up at the summit by different speakers.
> >
> > There was also a quick poll:
> >
> > 1. Kathy Giori asked the attendees to raise their hand if they backed the 
> > idea of an OpenWRT foundation
> > I would say half of the presents raised their hands (I did not because I'm 
> > not involved so much in OpenWRT and I don't feel entitled to take sides)
> >
> > 2. Kathy asked the attendees to raise their hand if they opposed the idea 
> > of an OpenWRT foundation
> > I think there were almost no raised hands or not at all

I believe it's important to note that OpenWrt got quite a lot of users
and contributers who aren't commercially motivated and probably didn't
feel the need to come to an industry-funded summit in first place.
Many here got their roots in the wifi-mesh communities, ie. they are
activists and afaik most of OpenWrt was created as a leasure/hobby
activity. (correct me if that's terribly wrong)
Sure, now that even chip vendors use OpenWrt as the base of their SDKs
and major industry players provide OpenWrt-based BSPs the situation
has certainly changed.
However, I believe the extraordinarily high quality of the code was and
is only possible due to the lack of commercial pressure and because
things were done when people liked to do them and took as long as they
would take (rather than doing stuff you don't feel like doing in that
moment because of some dead-line or commercially motivated commitment)
Quality[1] itself can be quite a good motivator for many of us, and is
imho impossible to achieve if driven by anything but passion and love
for the matter and activity itself (that doesn't mean that it's bad
to be paid for good work, there's nothing wrong with that).
Being a software engineer myself, I'm aware that this is not what $corp
managers believe, and surely, it's still hard work to build something
and most people do need to get paid for at least some of their work in
order to have a good live and not needing to starve.

But yet, it's like comparing arts with advertisement or love with
prostitution. Given these extreme examples, almost everyone can
grasp the difference in quality I'm talking about which also applies
here.

If you want an industry-driven fork, go ahead. But don't force that
model upon an existing community without understanding how major parts
of that said community is operating.
Sure, we can all use funding :)
But my mode-of-operation doesn't have a price-tag on it.
I hope that applies also to the decission-making of most long-term
contributers.


> 
> Wouldn't it be easier if the project is adopted by an umbrella
> organization? There should be one that could be interested in managing
> the pitfalls and dirty bits of the organization, allowing the
> developers to spend their time on the project itself - and not on the
> maintenance of a foundation.

However, I'm happy we are arriving at the core of that matter. It's
(as usual among the technical croud) hidden behind a technical debate,
in this case git vs. subversion.
However, what it is really about is the mode of decission-making and
commercial usability and reliability.

It's ok to use our music, but don't tell anyone how to play.
And sure, feel free to find the magic hat :)


Cheers


Daniel


 [1]: https://en.wikipedia.org/wiki/Pirsig's_metaphysics_of_Quality
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition / paid patch-checking

[Emmanuel Deloget]

Hello,

On Tue, Oct 13, 2015 at 1:04 PM, Nemesis  wrote:
>
> As far as I remember, there's no initiative going on, but the issue was 
> brought up at the summit by different speakers.
>
> There was also a quick poll:
>
> 1. Kathy Giori asked the attendees to raise their hand if they backed the 
> idea of an OpenWRT foundation
> I would say half of the presents raised their hands (I did not because I'm 
> not involved so much in OpenWRT and I don't feel entitled to take sides)
>
> 2. Kathy asked the attendees to raise their hand if they opposed the idea of 
> an OpenWRT foundation
> I think there were almost no raised hands or not at all

Wouldn't it be easier if the project is adopted by an umbrella
organization? There should be one that could be interested in managing
the pitfalls and dirty bits of the organization, allowing the
developers to spend their time on the project itself - and not on the
maintenance of a foundation.

> Federico
>

BR,

-- Emmanuel Deloget
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition / paid patch-checking

[Bastian Bittorf]

* Daniel Golle  [13.10.2015 16:53]:
> If you want an industry-driven fork, go ahead. But don't force that
> model upon an existing community without understanding how major parts
> of that said community is operating.

What I see since a long time, is that there is simply not
enough manpower for reviewing patches and "simple" maintainance
work (trac, buildbots) and this more and more leads to an unhappy
community and overloaded devs.

commercial pressure is'nt good, i agree - but maybe there is
a way to have at least 1 fulltime or 2 parttime devs.

bye, bastian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[David Lang]

On Tue, 13 Oct 2015, Roman Yeryomin wrote:



Would it be possible to track the revision number in an automated way even
in a git repo?  So store the r number, and automatically increment on
commits.  Not sure if that's an option, but it seems like it might address
the problem.



If a user is smart enough to commit something locally then he knows
what he is doing and is smart enough to report the changes he made.
It's so simple.


I think the concern is that someone may do this and then make the resulting 
images available to others to install.


David Lang
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Etienne Champetier]

Hi again,

2015-10-12 23:49 GMT+02:00 Etienne Champetier 
:

> Hi All,
>
> Here are some commands to make a "full" git repo, from the "trunk" repo
> (the only complaint that everyone agrees on)
> We keep git commit sha's for the trunk, and we add all branches/tags
>
> It needs some more tunning, but it's a good start :)
>
> 1) clone the trunk repo
> git clone git://git.openwrt.org/openwrt.git openwrt-git-svn
> cd openwrt-git-svn
>
> 2) init git svn
> git svn init -T"/trunk" -t"/tags" -b"/branches" --prefix="svn/" svn://
> svn.openwrt.org/openwrt
>
> 3) tell git that we already have trunk
> git update-ref refs/remotes/svn/trunk refs/remotes/origin/master
>
> 4) download all branches/tags (except trunk because we already have it)
> git svn fetch
>
> resulting .git/config
>
>> [core]
>> repositoryformatversion = 0
>> filemode = true
>> bare = false
>> logallrefupdates = true
>> [remote "origin"]
>> url = git://git.openwrt.org/openwrt.git
>> fetch = +refs/heads/*:refs/remotes/origin/*
>> [branch "master"]
>> remote = origin
>> merge = refs/heads/master
>> [svn-remote "svn"]
>> url = svn://svn.openwrt.org/openwrt
>> fetch = trunk:refs/remotes/svn/trunk
>> branches = branches/*:refs/remotes/svn/*
>> tags = tags/*:refs/remotes/svn/tags/*
>>
>
>
> original SO post: http://stackoverflow.com/a/12251845
>
> Good night
> Etienne
>

Who has access/is running the script to mirror the svn on git.openwrt.org ?
I would like to know the exact commands used to update the git mirror

Here is an exemple of what we can have (I don't want to migrate to github,
i'm using it out of simplicity)
for now svn tags are git branches
https://github.com/champtar/openwrt-full

to do that i've added to my .git/config (after step 4)

> [remote "champtar"]
> url = g...@github.com:champtar/openwrt-full.git
> fetch = +refs/heads/*:refs/remotes/champtar/*
> push = refs/remotes/svn/*:refs/heads/*
>

and pushed with:
git push --mirror champtar

some more reading
http://john.albin.net/git/convert-subversion-to-git
http://wiki.gnucash.org/wiki/Git_Svn_Mirror

Regards
Etienne
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Roman Yeryomin]

On 13 October 2015 at 23:08, David Lang  wrote:
> On Tue, 13 Oct 2015, Roman Yeryomin wrote:
>
>>>
>>> Would it be possible to track the revision number in an automated way
>>> even
>>> in a git repo?  So store the r number, and automatically increment on
>>> commits.  Not sure if that's an option, but it seems like it might
>>> address
>>> the problem.
>>>
>>
>> If a user is smart enough to commit something locally then he knows
>> what he is doing and is smart enough to report the changes he made.
>> It's so simple.
>
>
> I think the concern is that someone may do this and then make the resulting
> images available to others to install.

Someone can do this (change the revision) very easily now too (and
this is good, because allows using internal revision numbers for
custom fw builders), so there is no way you can protect from this (I
would even say there is no point in protecting from this).

Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[David Lang]

On Wed, 14 Oct 2015, Roman Yeryomin wrote:


On 13 October 2015 at 23:08, David Lang  wrote:

On Tue, 13 Oct 2015, Roman Yeryomin wrote:



Would it be possible to track the revision number in an automated way
even
in a git repo?  So store the r number, and automatically increment on
commits.  Not sure if that's an option, but it seems like it might
address
the problem.



If a user is smart enough to commit something locally then he knows
what he is doing and is smart enough to report the changes he made.
It's so simple.



I think the concern is that someone may do this and then make the resulting
images available to others to install.


Someone can do this (change the revision) very easily now too (and
this is good, because allows using internal revision numbers for
custom fw builders), so there is no way you can protect from this (I
would even say there is no point in protecting from this).


I think it's a good idea to encourage other builders to have a unique id in 
there. That's why I was talking earlier about adding the initials of the builder 
to the version string.


Even if they are compiling the same code, there are enough different ways to 
configure things that can cause problems that it's worth knowing if it's a stock 
build or a custom one.


David Lang
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Roman Yeryomin]

On 14 October 2015 at 00:20, David Lang  wrote:
> On Wed, 14 Oct 2015, Roman Yeryomin wrote:
>
>> On 13 October 2015 at 23:08, David Lang  wrote:
>>>
>>> On Tue, 13 Oct 2015, Roman Yeryomin wrote:
>>>
>
> Would it be possible to track the revision number in an automated way
> even
> in a git repo?  So store the r number, and automatically increment on
> commits.  Not sure if that's an option, but it seems like it might
> address
> the problem.
>

 If a user is smart enough to commit something locally then he knows
 what he is doing and is smart enough to report the changes he made.
 It's so simple.
>>>
>>>
>>>
>>> I think the concern is that someone may do this and then make the
>>> resulting
>>> images available to others to install.
>>
>>
>> Someone can do this (change the revision) very easily now too (and
>> this is good, because allows using internal revision numbers for
>> custom fw builders), so there is no way you can protect from this (I
>> would even say there is no point in protecting from this).
>
>
> I think it's a good idea to encourage other builders to have a unique id in
> there. That's why I was talking earlier about adding the initials of the
> builder to the version string.
>
> Even if they are compiling the same code, there are enough different ways to
> configure things that can cause problems that it's worth knowing if it's a
> stock build or a custom one.

You can put any initials (or other info) into your version number or
other configurable identifiers, but, IMO, forcing this is a bad idea.

Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Bruno Randolf]

On 10/13/2015 09:08 PM, David Lang wrote:
> On Tue, 13 Oct 2015, Roman Yeryomin wrote:
> 
>>>
>>> Would it be possible to track the revision number in an automated way
>>> even
>>> in a git repo?  So store the r number, and automatically increment on
>>> commits.  Not sure if that's an option, but it seems like it might
>>> address
>>> the problem.
>>>
>>
>> If a user is smart enough to commit something locally then he knows
>> what he is doing and is smart enough to report the changes he made.
>> It's so simple.
> 
> I think the concern is that someone may do this and then make the
> resulting images available to others to install.

One way to avoid the ambiguity of the r-number would be to use
"git describe origin/master" then even if the local master branch has
commits, you'd get the "upstream" revision number. But, I think it's
more important to know that there have been local changes.

bruno
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Javier Domingo Cansino]

>
> One way to avoid the ambiguity of the r-number would be to use
> "git describe origin/master" then even if the local master branch has
> commits, you'd get the "upstream" revision number. But, I think it's
> more important to know that there have been local changes.
>

The git-describe two liner I traced that. Anyway, we don't really need a
number from version X because it's meaningless in git.

We've talked about how we would obtain the fork point, and a solution is
been already been stated (take Bruno's, mine, combine them, etc)

It is also clear that we can create tools to make testing PRs directly from
Github/Gitlab avoiding checkouts and just applying the patches, also we are
able to run checks automatically on PRs without intervention.

What is there left?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Steven Barth]

>
> Step 5 is unnecessary, patchwork sends emails on status changes.
Okay, it seems it does this only for the original submitter, right?
I guess it might come in handy to send it to the ML as well, or at
least make that possible in the WebUI.

> I usually copy the mbox link from patchwork and do this: wget -O-  | 
> git am
Yes, I guess that is easier than pwclient. Though it doesn't solve patchsets 
really.


>
>> Compared to Github, Gitlab or Gerrit this is bullshit.
> Even with those, there is some bouncing around in counter-intuitive ways
> if your process includes testing a commit before pushing it.
Yes, this is true and I see that really as the main valid point for criticism.
Ideally you want the "magic merge" only happen to your (local?) branch
and not the main one and then manually send off a batch of staged commits
manually via git push, so that would be the downside of using one of those
tools.

> What would your preferred workflow be? Please list the exact series of
> steps for it.
So to summarize, based on the current workflow:
1. Be able to send mails (and change status) from within patchwork, e.g.
how you can do it in trac, just that it gets send out to the ML and the 
author instead
of being just hidden in some UI.

2. Download a whole set of the patches (e.g. one patch series)
without having to do it for all patches indivdually (e.g. like Github let's 
you download
a whole pull-request as a single patchfile). I'm fine with it even not 
keeping track what
patches belong to which series, but just having e.g. a page with checkboxes 
where
I can tick patches and some where on the bottom click "download series as 
.patch".

3. Have some kind of tool that applies stuff locally (but I guess one could 
write some
handler and associate that with .mbox or .patch and just click on the 
downloaded
patch (serieses) and apply them like that).

4. Ideally have some sort of integration with a bugtracker.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Steven Barth]

Let's face it though: the current workflow wrt. core patches is crappy.

1. Go to patchwork, see if there is a patch
2. If you want to comment, switch to mail client, find thread, write reply.
3. If you want to commit: download patch, go to command line, see if it applies
4. Then manually go back to patchwork and adjust the status of the patch.
5. Upon merging go back to mail and write a mail ala "Patch Accepted".


Sure could use pwclient and ocassionally do, however it does essentially one 
thing
only: save me the download step. Yes, I can also save me the click back to the
browser to hit accept and can do that via CLI (if I remember the cryptic 
switches).
On top of that now I have to deal with an opaque 5 or 6-digit patch id in my 
head.

Compared to Github, Gitlab or Gerrit this is bullshit.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 08:38, Steven Barth wrote:
> Let's face it though: the current workflow wrt. core patches is crappy.
> 
> 1. Go to patchwork, see if there is a patch
> 2. If you want to comment, switch to mail client, find thread, write reply.
> 3. If you want to commit: download patch, go to command line, see if it 
> applies
> 4. Then manually go back to patchwork and adjust the status of the patch.
> 5. Upon merging go back to mail and write a mail ala "Patch Accepted".
Step 5 is unnecessary, patchwork sends emails on status changes.

> Sure could use pwclient and ocassionally do, however it does essentially one 
> thing
> only: save me the download step. Yes, I can also save me the click back to the
> browser to hit accept and can do that via CLI (if I remember the cryptic 
> switches).
> On top of that now I have to deal with an opaque 5 or 6-digit patch id in my 
> head.
I usually copy the mbox link from patchwork and do this:
wget -O-  | git am

> Compared to Github, Gitlab or Gerrit this is bullshit.
Even with those, there is some bouncing around in counter-intuitive ways
if your process includes testing a commit before pushing it.

What would your preferred workflow be? Please list the exact series of
steps for it.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[John Crispin]

On 12/10/2015 09:07, Steven Barth wrote:
> And don't get me started about having a completely different Issuetracker with
> different credentials etc.

indeed there i this thing called trac which i wonder if people actually
use/look at.

so we really have 3 issues at hand

1) switch the core tree to using git
2) make sure that release branches have a history
3) pull from github trees

1) & 2) are just technical / organizational issues i guess

as for 3), if we move to gihub we have yet another entry point that we
need to look after. ok, we could close trac but that would just move the
"noise" from one place to another. obsoleting the rest of the existing
infra is also a bit quirky i guess as people are using it actively.

there is nothing stopping you right now from setting up a say "network
susbsystem" tree on github that you pull your patches into and once you
have your tree ready you can simply push the changes to the master tree.

John
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Steven Barth]

>> Let's face it though: the current workflow wrt. core patches is crappy.
>>
>> 1. Go to patchwork, see if there is a patch
>> 2. If you want to comment, switch to mail client, find thread, write reply.
>> 3. If you want to commit: download patch, go to command line, see if it 
>> applies
>> 4. Then manually go back to patchwork and adjust the status of the patch.
>> 5. Upon merging go back to mail and write a mail ala "Patch Accepted".
>>
>>
>> Sure could use pwclient and ocassionally do, however it does essentially one 
>> thing
>> only: save me the download step. Yes, I can also save me the click back to 
>> the
>> browser to hit accept and can do that via CLI (if I remember the cryptic 
>> switches).
>> On top of that now I have to deal with an opaque 5 or 6-digit patch id in my 
>> head.
>>
>> Compared to Github, Gitlab or Gerrit this is bullshit.
>>
>
> lets face it, it works very well. if you find it crappy then please
> provide consistent reasons why this is so.
If you find the steps above a sensible workflow,  i.e., I essentially need to 
switch
between 3 different programs having no connection between one another at all
to merge a patch then I don't know what arguments could actually convince you.


> currently having people look at every patch while merging it is very
> usefull and leads to a solid codebase.
So, the assumptions is, because its email everyone reads everything and 
magically
doesn't filter by subject etc. and when you switch to Gitlab or similar people 
suddenly
change?

Tbh. I don't care if its email or some sort of web-based stuff, as long as 
tracking
the patches actually doesn't add more overhead than it delivers value aka. the 
way
we use patchwork.

If we had a patch-tracker that let's me reply (send mail) directly from the gui 
and
optionally doesn't make it a stupid hassle to merge a whole patchset then I 
don't
have a problem with e-mail. I'm sorry that I actually value my free time when 
doing
either volunteer or paid work.

And don't get me started about having a completely different Issuetracker with
different credentials etc.

> having the github "click and merge" stuff will lead to people "clicking
> and merging" and not reviewing it properly.
So, you don't trust the same group of people having push-access if they
would be using a web-interface over the current e-mail approach?

> i understand that some people love to upload their data to us based
> cloud services. but then again i would argue that this is a really illy
> thing to do for a whole number of reasons. first of all our dependence
> on that $corporation
Right, because a self-hosted Gitlab or Gerrit instance will send data to the US.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[John Crispin]

On 12/10/2015 09:36, Felix Fietkau wrote:
>> Sure could use pwclient and ocassionally do, however it does essentially one 
>> thing
>> > only: save me the download step. Yes, I can also save me the click back to 
>> > the
>> > browser to hit accept and can do that via CLI (if I remember the cryptic 
>> > switches).
>> > On top of that now I have to deal with an opaque 5 or 6-digit patch id in 
>> > my head.
> I usually copy the mbox link from patchwork and do this:
> wget -O-  | git am
> 

#!/bin/sh

wget http://patchwork.ozlabs.org/patch/$1/mbox/ -O $1.patch

[ -f $1.patch ] || {
echo "unknown patchwork id"
exit 1
}

git am --3way $1.patch
[ $? = 0 ] || {
mkdir -p fails
cp $1.patch fails/
git am --abort
echo applying $1 FAILED
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[James Hilliard]

What do you think about using something like Jira for project
management(which is free for open source projects)? I know it was used by
cyanogenmod with decent success. One other potential advantage would be the
possibility of CI testing being tied in more closely.

On Mon, Oct 12, 2015 at 1:46 AM, John Crispin  wrote:

>
>
> On 12/10/2015 08:38, Steven Barth wrote:
> > Let's face it though: the current workflow wrt. core patches is crappy.
> >
> > 1. Go to patchwork, see if there is a patch
> > 2. If you want to comment, switch to mail client, find thread, write
> reply.
> > 3. If you want to commit: download patch, go to command line, see if it
> applies
> > 4. Then manually go back to patchwork and adjust the status of the patch.
> > 5. Upon merging go back to mail and write a mail ala "Patch Accepted".
> >
> >
> > Sure could use pwclient and ocassionally do, however it does essentially
> one thing
> > only: save me the download step. Yes, I can also save me the click back
> to the
> > browser to hit accept and can do that via CLI (if I remember the cryptic
> switches).
> > On top of that now I have to deal with an opaque 5 or 6-digit patch id
> in my head.
> >
> > Compared to Github, Gitlab or Gerrit this is bullshit.
> >
>
>
> lets face it, it works very well. if you find it crappy then please
> provide consistent reasons why this is so.
>
> so far this thread has brought fwd that
>
> * it is crappy
> * Turrit does not work well
> * we think github is better
> * the version history gets lost
>
> the only valid argument i have seen so far is that the history gets
> lost. the rest is just web20 convenient feature requirements.
>
> currently having people look at every patch while merging it is very
> usefull and leads to a solid codebase.
>
> having the github "click and merge" stuff will lead to people "clicking
> and merging" and not reviewing it properly.
>
> i understand that some people love to upload their data to us based
> cloud services. but then again i would argue that this is a really illy
> thing to do for a whole number of reasons. first of all our dependence
> on that $corporation
>
> John
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[John Crispin]

On 12/10/2015 08:38, Steven Barth wrote:
> Let's face it though: the current workflow wrt. core patches is crappy.
> 
> 1. Go to patchwork, see if there is a patch
> 2. If you want to comment, switch to mail client, find thread, write reply.
> 3. If you want to commit: download patch, go to command line, see if it 
> applies
> 4. Then manually go back to patchwork and adjust the status of the patch.
> 5. Upon merging go back to mail and write a mail ala "Patch Accepted".
> 
> 
> Sure could use pwclient and ocassionally do, however it does essentially one 
> thing
> only: save me the download step. Yes, I can also save me the click back to the
> browser to hit accept and can do that via CLI (if I remember the cryptic 
> switches).
> On top of that now I have to deal with an opaque 5 or 6-digit patch id in my 
> head.
> 
> Compared to Github, Gitlab or Gerrit this is bullshit.
> 


lets face it, it works very well. if you find it crappy then please
provide consistent reasons why this is so.

so far this thread has brought fwd that

* it is crappy
* Turrit does not work well
* we think github is better
* the version history gets lost

the only valid argument i have seen so far is that the history gets
lost. the rest is just web20 convenient feature requirements.

currently having people look at every patch while merging it is very
usefull and leads to a solid codebase.

having the github "click and merge" stuff will lead to people "clicking
and merging" and not reviewing it properly.

i understand that some people love to upload their data to us based
cloud services. but then again i would argue that this is a really illy
thing to do for a whole number of reasons. first of all our dependence
on that $corporation

John
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Roman Yeryomin]

On 12 October 2015 at 10:36, Felix Fietkau  wrote:
> On 2015-10-12 08:38, Steven Barth wrote:
>> Let's face it though: the current workflow wrt. core patches is crappy.
>>
>> 1. Go to patchwork, see if there is a patch
>> 2. If you want to comment, switch to mail client, find thread, write reply.
>> 3. If you want to commit: download patch, go to command line, see if it 
>> applies
>> 4. Then manually go back to patchwork and adjust the status of the patch.
>> 5. Upon merging go back to mail and write a mail ala "Patch Accepted".
> Step 5 is unnecessary, patchwork sends emails on status changes.

I think that workflow changes could introduce some pain but those can
be left aside (t.i. kept as is for now) until people get used to git
more and, maybe, develop some new/optimized workflow.
One benefit what git would give, independently from which (main)
workflow is used, is branching, which, IMO, is quite cumbersome right
now.

Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Javier Domingo Cansino]

>
> that reminded me to check, and indeed, I only use
> git://git.openwrt.org/openwrt.git anyway :)
>
​
I do use the openwrt mirror github hosts, and I suppose is mirroring that
one.

I think it's already given all the points in Git vs SVN, so I will speak
about self hosting and git interfaces.

I suppose many of you have already worked with Github, Gitlab, gitolite and
gerrit for hosting. I reviewed a book on gitolite a few years ago, I have
been using Github for past 5 years, and made some Gitlab CE self-hosted
instalations.

First of all, I don't like gerrit because of the workflow it imposes and
the limitations compared to Gitlab/Github. gitolite doesn't have a web
interface, is just a git hosting tool, which btw is used for linux dev
since kernel.org was compromised. And gitlab/github are pretty similar.

If you are not willing to change the workflow, nor giving any kind of
enhanced experience, you should probably go with gitolite. It's easy to
manage, and it allows you to manage permissions per-branch, and does even
let you deny pushes depending on the path you modify. Which I have read is
interesting for maintainers. It's a really extensible and complete hosting
tool.

However, I firmly believe that if you are going through any kind of
changing process, you should probably stick with the most accessible tool.

I would propose you installed/hired Gitlab, changed the project to git,
continue with the same workflow, and then decide a proper workflow for your
project while you get accustomed to the new interface. Later, you can
switch to using the gitlab issues / forks / merge requests.

There are tools to migrate issues between systems, so if desired,
historical issues could be maintained.

​I would however not use submodules. You can just rip off the kernel and
treat it as another project, which in my opinion is the best way of
handling multiple projects, rather than including submodules for everything.

Anyway, that last bit it's ok if you want to go with it, from my
experience, I really don't like it, but I have seen project do good with it.


-- 
Javier Domingo Cansino
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Holger Levsen]

Hi,

(just a tiny datapoint...)

On Montag, 12. Oktober 2015, Felix Fietkau wrote:
> Which part is cumbersome for you and how exactly would switching the
> main repo to git solve it?

*g*

that reminded me to check, and indeed, I only use 
git://git.openwrt.org/openwrt.git anyway :)

I *guess* most people can base their work on this anyway already, so maybe 
just give the poor souls still using svn some slack, until they find time and 
ressources to migrate? ;-)


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 10:14, Steven Barth wrote:
>> What would your preferred workflow be? Please list the exact series of
>> steps for it.
> So to summarize, based on the current workflow:
> 1. Be able to send mails (and change status) from within patchwork, e.g.
> how you can do it in trac, just that it gets send out to the ML and the 
> author instead
> of being just hidden in some UI.
Maybe you could suggest that to the patchwork author.

> 2. Download a whole set of the patches (e.g. one patch series)
> without having to do it for all patches indivdually (e.g. like Github 
> let's you download
> a whole pull-request as a single patchfile). I'm fine with it even not 
> keeping track what
> patches belong to which series, but just having e.g. a page with 
> checkboxes where
> I can tick patches and some where on the bottom click "download series as 
> .patch".
Just select a bunch of patches, put in a name at the bottom of the page
and click "Create bundle". You can download that bundle as .mbox

> 3. Have some kind of tool that applies stuff locally (but I guess one could 
> write some
> handler and associate that with .mbox or .patch and just click on the 
> downloaded
> patch (serieses) and apply them like that).
> 
> 4. Ideally have some sort of integration with a bugtracker.
What kind of integration and for what purpose?

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Nemesis]

On 10/12/2015 09:44 AM, John Crispin wrote:
> On 12/10/2015 09:07, Steven Barth wrote:
>> > And don't get me started about having a completely different Issuetracker 
>> > with
>> > different credentials etc.
> indeed there i this thing called trac which i wonder if people actually
> use/look at.
>
> so we really have 3 issues at hand
>
> 1) switch the core tree to using git
> 2) make sure that release branches have a history
> 3) pull from github trees
>
> 1) & 2) are just technical / organizational issues i guess
>
> as for 3), if we move to gihub we have yet another entry point that we
> need to look after. ok, we could close trac but that would just move the
> "noise" from one place to another. obsoleting the rest of the existing
> infra is also a bit quirky i guess as people are using it actively.

The Django Framework moved from SVN to github in 2012but they kept their
own bug tracker (which they redesigned with some funding to make it more
usable): https://code.djangoproject.com/

I think they're a good example of an open source community which went
through the process of improving the way people can join the community
and contribute, they also raise funds to pay for hard tasks like
redesigning the website, organizing sprints, periodically hire a
"fellow" which reviews (accepts/closes and occasionally fixes) tickets
and so on.
Since they started doing this django has improved massively.

I understand the desire to self host, so I suggest to take a look at
gitlab community edition.

Federico


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 10:43, Roman Yeryomin wrote:
> On 12 October 2015 at 10:36, Felix Fietkau  wrote:
>> On 2015-10-12 08:38, Steven Barth wrote:
>>> Let's face it though: the current workflow wrt. core patches is crappy.
>>>
>>> 1. Go to patchwork, see if there is a patch
>>> 2. If you want to comment, switch to mail client, find thread, write reply.
>>> 3. If you want to commit: download patch, go to command line, see if it 
>>> applies
>>> 4. Then manually go back to patchwork and adjust the status of the patch.
>>> 5. Upon merging go back to mail and write a mail ala "Patch Accepted".
>> Step 5 is unnecessary, patchwork sends emails on status changes.
> 
> I think that workflow changes could introduce some pain but those can
> be left aside (t.i. kept as is for now) until people get used to git
> more and, maybe, develop some new/optimized workflow.
> One benefit what git would give, independently from which (main)
> workflow is used, is branching, which, IMO, is quite cumbersome right
> now.
Which part is cumbersome for you and how exactly would switching the
main repo to git solve it?

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Steven Barth]

>>> What would your preferred workflow be? Please list the exact series of
>>> steps for it.
>> So to summarize, based on the current workflow:
>> 1. Be able to send mails (and change status) from within patchwork, e.g.
>> how you can do it in trac, just that it gets send out to the ML and the 
>> author instead
>> of being just hidden in some UI.
> Maybe you could suggest that to the patchwork author.
I guess so.


>
>> 2. Download a whole set of the patches (e.g. one patch series)
>> without having to do it for all patches indivdually (e.g. like Github 
>> let's you download
>> a whole pull-request as a single patchfile). I'm fine with it even not 
>> keeping track what
>> patches belong to which series, but just having e.g. a page with 
>> checkboxes where
>> I can tick patches and some where on the bottom click "download series 
>> as .patch".
> Just select a bunch of patches, put in a name at the bottom of the page
> and click "Create bundle". You can download that bundle as .mbox
Yeah using bundles can sort of do that, but it can get cumbersome quickly as 
well.
You first have to select the patches and create a new bundle, then click on 
bundles,
and click download for the new bundle which I guess is somewhat reasonable.

However once you are done, you have to either - remove accepted patches from the
bundle or kill the whole bundle and start over next time, because the bundle 
always gets
you all patches in it, including the ones accepted or rejected. I guess again, 
its a start but
needs some improvements to feel really convenient. Maybe suggesting a second 
button
to the author "download patches needing action" or so, would do it.


>
>> 4. Ideally have some sort of integration with a bugtracker.
> What kind of integration and for what purpose?
It's mainly having some tool that is integrated, i.e., uses same credentials 
and maybe even the
possibility to close related tickets just by accepting the patches. Using 
entirely different tools just
feels a bit unnecessary. I do not consider that to be an essential issue 
really, more like a nice to have
which you get to like when working with more integrated environments.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Roman Yeryomin]

On 12 October 2015 at 12:04, Holger Levsen  wrote:
> Hi,
>
> (just a tiny datapoint...)
>
> On Montag, 12. Oktober 2015, Felix Fietkau wrote:
>> Which part is cumbersome for you and how exactly would switching the
>> main repo to git solve it?
>
> *g*
>
> that reminded me to check, and indeed, I only use
> git://git.openwrt.org/openwrt.git anyway :)
>

Exactly.
Cumbersome is having multiple repositories, which was probably a
workaround to painful (as opposed to git) branching in svn. At least
it looks like that.

Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 11:44, Javier Domingo Cansino wrote:
> that reminded me to check, and indeed, I only use
> git://git.openwrt.org/openwrt.git
>  anyway :)
> 
> ​
> I do use the openwrt mirror github hosts, and I suppose is mirroring
> that one.
> 
> I think it's already given all the points in Git vs SVN, so I will speak
> about self hosting and git interfaces.
> 
> I suppose many of you have already worked with Github, Gitlab, gitolite
> and gerrit for hosting. I reviewed a book on gitolite a few years ago, I
> have been using Github for past 5 years, and made some Gitlab CE
> self-hosted instalations.
> 
> First of all, I don't like gerrit because of the workflow it imposes and
> the limitations compared to Gitlab/Github. gitolite doesn't have a web
> interface, is just a git hosting tool, which btw is used for linux dev
> since kernel.org  was compromised. And gitlab/github
> are pretty similar.
> 
> If you are not willing to change the workflow, nor giving any kind of
> enhanced experience, you should probably go with gitolite. It's easy to
> manage, and it allows you to manage permissions per-branch, and does
> even let you deny pushes depending on the path you modify. Which I have
> read is interesting for maintainers. It's a really extensible and
> complete hosting tool.
FYI, we are already using gitolite on git.openwrt.org.

> However, I firmly believe that if you are going through any kind of
> changing process, you should probably stick with the most accessible tool.
> 
> I would propose you installed/hired Gitlab, changed the project to git,
> continue with the same workflow, and then decide a proper workflow for
> your project while you get accustomed to the new interface. Later, you
> can switch to using the gitlab issues / forks / merge requests.
While it works fine for packages, I don't think the pull request stuff
is very usable for OpenWrt core, which has a more centralized
development model.
One reason why we haven't moved the main repo to git yet is that we lose
the advantage of having revision numbers that propagate to the firmware,
even with builds from a forked repository where some commits have been
added on top.
If we do everything in git, we either have to constantly remember to tag
revisions, or we will lose valuable information when users report bugs
with forked repos.
I also happen to like linear history very much, and SVN enforces that ;)

> There are tools to migrate issues between systems, so if desired,
> historical issues could be maintained.
> 
> ​I would however not use submodules. You can just rip off the kernel and
> treat it as another project, which in my opinion is the best way of
> handling multiple projects, rather than including submodules for everything.
I still believe for our maintenance process it's a bad idea to maintain
the kernel as a separate git repository. With generic changes, it's easy
to lose track of what patch has been applied in which branch, and
syncing them can be annoying with rebases.
Also, pulling changes is going to be confusing for users as well, since
we will have to constantly rebase branches.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Javier Domingo Cansino]

>
> > since kernel.org  was compromised. And gitlab/github
> > are pretty similar.
>

Sure, just giving some background on where gitolite was being used and the
less-known features it has.

While it works fine for packages, I don't think the pull request stuff
> is very usable for OpenWrt core, which has a more centralized
> development model.
> One reason why we haven't moved the main repo to git yet is that we lose
> the advantage of having revision numbers that propagate to the firmware,
> even with builds from a forked repository where some commits have been
> added on top.
> If we do everything in git, we either have to constantly remember to tag
> revisions, or we will lose valuable information when users report bugs
> with forked repos.
> I also happen to like linear history very much, and SVN enforces that ;)
>
You can enforce linear history by denying history rewrites. It's what they
call now protected branches (IIRC), and I think you can really enforce
that. Also, you can create hooks to check for tagging info etc.

I don't fully understand the 'remember to tag revision' thing.

I still believe for our maintenance process it's a bad idea to maintain
> the kernel as a separate git repository. With generic changes, it's easy
> to lose track of what patch has been applied in which branch, and
> syncing them can be annoying with rebases.
> Also, pulling changes is going to be confusing for users as well, since
> we will have to constantly rebase branches.
>

What I had in mind for the kernel consisted on some similar workflow to the
one gitlab uses for their stable branches. You have a branch for each
maintained kernel release, and you have all the commit's cherry-picked from
the master.

Of course, you can always use rebase and apply all the patches in order. It
is possible to have scripts that actually make sure every patch is applied,
letting you substract patch lists, etc.

Making maintainable the support for several different versions of kernel,
each one on it's branch, forking from the official repo.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Sergey Ryazanov]

Too many voices, which blame svn and almost no advocates. So let me
change this situation.

As an occasional patch maker, I am fairly happy with current workflow
based on git+svn mix. I *think* that this is a good solution exactly
in this case and for this project. May be some random project could
not continue growth without full migration to git, but as a random
developer I don't see any benefits for me in this particular case.

And, as I already wrote, I really like linear history and short
revision numbers of SVN :)

-- 
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 15:09, Javier Domingo Cansino wrote:
> Right now, the revision number (r) is really useful to figure
> out what particular openwrt version is being used, when people report
> bugs. The commit hash cannot be used as a replacement, since it might be
> one that isn't present in the official repo.
> When using tags as a starting point (via git describe), somebody has to
> create those tags, which is cumbersome (and would mean adding lots of
> useless ones).
> 
> The tags would be the major versions and RCs. I don't believe other tags
> should be used.
> 
> Apart from that, I understand that if someone cloned the SVN repo (full
> svn history), created it's own server, and developed on top of a given
> revision X, the same problem would arise.
I haven't seen a single instance of somebody doing this, and in my
opinion it would be kind of stupid anyway :)
We don't even advertise the SVN server URL to users anymore for a reason.

> I don't find this as a valid argument because that's up to the user.
> Either you fork from official owrt and note down the commit you forked
> in to give as a reference, or you provide full access to your source
> code, where you can actually see when it forked through git merge-base
> --fork-point.
And you think users will actually do that? Based on previous experience,
I really don't. The way it's set up right now, people can fork as they
wish and the scripts automatically determining the OpenWrt base version
will just work.

> And of course, you can always automatically generate with help from
> git-describe a relative revision from the fork-point. Anyway, it would
> be up to the forkers to decide whether they want to rebase their tree or
> merge your tree.
It's not about what you theoretically can do, it's about what users will
end up doing.

> Well, we have per-target kernel patches. Patches from different targets
> might conflict with each other, or might break unrelated targets.
> Dealing with that would mean either carefully reviewing every single
> target patch to avoid negative side effects for other targets, or
> maintaining one branch per target.
> For both variants, the amount of extra work this creates in my opinion
> vastly outweighs the benefits of using git for the kernel tree.
> 
> I believe that we could find a mix between per kernel version patches
> and per target patches. Probably the best would be to treat the openwrt
> kernel as a project forking from linux-stable (I believe it's the
> tarballs you are currently using), and use that owrt kernel as a base to
> apply the per target patches (at the end, each target has it's own
> specific patches).
Wow, now you're making it really confusing for everybody involved. Some
changes live in an external git repo, some changes live as patches, and
whenever the external repo changes we're supposed to update the revision
in the OpenWrt tree?

> I find it as repackaging the same project with different patches to add
> functionality.
> 
> I'm open to changing my mind if I see some compelling arguments, but
> right now I believe the extra maintenance cost vastly outweighs the
> potential benefits.
> 
> My proposal of steps to migrate to git would be.
>  1) openwrt to git, maintaining even the workflow as it is, giving time
> to deal with all the differences to svn (such as the relative revision
> crafting etc).
I haven't seen any proposal that deals with the revision crafting issue
in a practical and useful way. I also haven't seen many compelling
arguments about what the practical benefit of these changes would be.

I see repeated claims that assume that having patches in a git repo will
make it easier to upstream stuff, and I just don't believe those claims
without a proper explanation.

> Once everyone is comfortable with the git based hosting, I would go for
> 2) adapting the workflow to the tools git provides. We would be talking
> there about how merge requests are handled, web interfaces, etc.
> Finally, I would go for step 3) check how we can improve the owrt-kernel
> relationship.
> 
> Of course, the 3rd step, if based in my idea, doesn't need to be done
> before 1/2. Also, steps 1,2 can be done at once.
Before you try to convince us to change the workflow, I would really
like to see a *detailed* explanation of how this would actually help us.
If you really believe that this would be a good fit, then you will have
to be a lot more specific about the potential benefits.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Javier Domingo Cansino]

>
> Right now, the revision number (r) is really useful to figure
> out what particular openwrt version is being used, when people report
> bugs. The commit hash cannot be used as a replacement, since it might be
> one that isn't present in the official repo.
> When using tags as a starting point (via git describe), somebody has to
> create those tags, which is cumbersome (and would mean adding lots of
> useless ones).
>
The tags would be the major versions and RCs. I don't believe other tags
should be used.

Apart from that, I understand that if someone cloned the SVN repo (full svn
history), created it's own server, and developed on top of a given revision
X, the same problem would arise.

I don't find this as a valid argument because that's up to the user. Either
you fork from official owrt and note down the commit you forked in to give
as a reference, or you provide full access to your source code, where you
can actually see when it forked through git merge-base --fork-point.

And of course, you can always automatically generate with help from
git-describe a relative revision from the fork-point. Anyway, it would be
up to the forkers to decide whether they want to rebase their tree or merge
your tree.

Well, we have per-target kernel patches. Patches from different targets
> might conflict with each other, or might break unrelated targets.
> Dealing with that would mean either carefully reviewing every single
> target patch to avoid negative side effects for other targets, or
> maintaining one branch per target.
> For both variants, the amount of extra work this creates in my opinion
> vastly outweighs the benefits of using git for the kernel tree.
>
> I believe that we could find a mix between per kernel version patches and
per target patches. Probably the best would be to treat the openwrt kernel
as a project forking from linux-stable (I believe it's the tarballs you are
currently using), and use that owrt kernel as a base to apply the per
target patches (at the end, each target has it's own specific patches).

I find it as repackaging the same project with different patches to add
functionality.

I'm open to changing my mind if I see some compelling arguments, but
> right now I believe the extra maintenance cost vastly outweighs the
> potential benefits.
>
My proposal of steps to migrate to git would be.
 1) openwrt to git, maintaining even the workflow as it is, giving time to
deal with all the differences to svn (such as the relative revision
crafting etc).
Once everyone is comfortable with the git based hosting, I would go for 2)
adapting the workflow to the tools git provides. We would be talking there
about how merge requests are handled, web interfaces, etc.
Finally, I would go for step 3) check how we can improve the owrt-kernel
relationship.

Of course, the 3rd step, if based in my idea, doesn't need to be done
before 1/2. Also, steps 1,2 can be done at once.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 14:29, Javier Domingo Cansino wrote:
> While it works fine for packages, I don't think the pull request stuff
> is very usable for OpenWrt core, which has a more centralized
> development model.
> One reason why we haven't moved the main repo to git yet is that we lose
> the advantage of having revision numbers that propagate to the firmware,
> even with builds from a forked repository where some commits have been
> added on top.
> If we do everything in git, we either have to constantly remember to tag
> revisions, or we will lose valuable information when users report bugs
> with forked repos.
> I also happen to like linear history very much, and SVN enforces that ;)
> 
> You can enforce linear history by denying history rewrites. It's what
> they call now protected branches (IIRC), and I think you can really
> enforce that. Also, you can create hooks to check for tagging info etc. 
> 
> I don't fully understand the 'remember to tag revision' thing.
Right now, the revision number (r) is really useful to figure
out what particular openwrt version is being used, when people report
bugs. The commit hash cannot be used as a replacement, since it might be
one that isn't present in the official repo.
When using tags as a starting point (via git describe), somebody has to
create those tags, which is cumbersome (and would mean adding lots of
useless ones).

> I still believe for our maintenance process it's a bad idea to maintain
> the kernel as a separate git repository. With generic changes, it's easy
> to lose track of what patch has been applied in which branch, and
> syncing them can be annoying with rebases.
> Also, pulling changes is going to be confusing for users as well, since
> we will have to constantly rebase branches.
> 
>  
> What I had in mind for the kernel consisted on some similar workflow to
> the one gitlab uses for their stable branches. You have a branch for
> each maintained kernel release, and you have all the commit's
> cherry-picked from the master.
Well, we have per-target kernel patches. Patches from different targets
might conflict with each other, or might break unrelated targets.
Dealing with that would mean either carefully reviewing every single
target patch to avoid negative side effects for other targets, or
maintaining one branch per target.
For both variants, the amount of extra work this creates in my opinion
vastly outweighs the benefits of using git for the kernel tree.

> Of course, you can always use rebase and apply all the patches in order.
> It is possible to have scripts that actually make sure every patch is
> applied, letting you substract patch lists, etc.
If we keep rebasing, people get confused when working on the tree and
running git pull.

> Making maintainable the support for several different versions of
> kernel, each one on it's branch, forking from the official repo.
I'm open to changing my mind if I see some compelling arguments, but
right now I believe the extra maintenance cost vastly outweighs the
potential benefits.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Bruno Randolf]

On 10/12/2015 01:43 PM, Felix Fietkau wrote:
> When using tags as a starting point (via git describe), somebody has to
> create those tags, which is cumbersome (and would mean adding lots of
> useless ones).

What's cumbersome? And why would you have to create useless tags?

I would actually take this argument on the reverse and say it's good,
because it forces you to tag revisions which should be tagged (like
"15.05-rc1", "15.05").

bruno
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Sergey Ryazanov]

2015-10-12 15:04 GMT+03:00 Felix Fietkau :
> While it works fine for packages, I don't think the pull request stuff
> is very usable for OpenWrt core, which has a more centralized
> development model.
> One reason why we haven't moved the main repo to git yet is that we lose
> the advantage of having revision numbers that propagate to the firmware,
> even with builds from a forked repository where some commits have been
> added on top.
> If we do everything in git, we either have to constantly remember to tag
> revisions, or we will lose valuable information when users report bugs
> with forked repos.
> I also happen to like linear history very much, and SVN enforces that ;)
>

+1

IMHO, this is the most useful capability of SVN for core of big projects.

-- 
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Roman Yeryomin]

On 12 October 2015 at 16:34, Felix Fietkau  wrote:
> On 2015-10-12 15:09, Javier Domingo Cansino wrote:
>> Right now, the revision number (r) is really useful to figure
>> out what particular openwrt version is being used, when people report
>> bugs. The commit hash cannot be used as a replacement, since it might be
>> one that isn't present in the official repo.
>> When using tags as a starting point (via git describe), somebody has to
>> create those tags, which is cumbersome (and would mean adding lots of
>> useless ones).
>>
>> The tags would be the major versions and RCs. I don't believe other tags
>> should be used.
>>
>> Apart from that, I understand that if someone cloned the SVN repo (full
>> svn history), created it's own server, and developed on top of a given
>> revision X, the same problem would arise.
> I haven't seen a single instance of somebody doing this, and in my
> opinion it would be kind of stupid anyway :)
> We don't even advertise the SVN server URL to users anymore for a reason.
>

IMO git describe --dirty would work perfectly. You would see a short
hash and if user modified it or not.
For users it would work even better than svn revision.
For devs or users who do commit locally both svn and git "revisions"
can be "spoofed" anyway so it just useless.
oh.. sorry, I forgot that you cannot commit locally with svn...

Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 16:11, Roman Yeryomin wrote:
> On 12 October 2015 at 16:34, Felix Fietkau  wrote:
>> On 2015-10-12 15:09, Javier Domingo Cansino wrote:
>>> Right now, the revision number (r) is really useful to figure
>>> out what particular openwrt version is being used, when people report
>>> bugs. The commit hash cannot be used as a replacement, since it might be
>>> one that isn't present in the official repo.
>>> When using tags as a starting point (via git describe), somebody has to
>>> create those tags, which is cumbersome (and would mean adding lots of
>>> useless ones).
>>>
>>> The tags would be the major versions and RCs. I don't believe other tags
>>> should be used.
>>>
>>> Apart from that, I understand that if someone cloned the SVN repo (full
>>> svn history), created it's own server, and developed on top of a given
>>> revision X, the same problem would arise.
>> I haven't seen a single instance of somebody doing this, and in my
>> opinion it would be kind of stupid anyway :)
>> We don't even advertise the SVN server URL to users anymore for a reason.
>>
> 
> IMO git describe --dirty would work perfectly. You would see a short
> hash and if user modified it or not.
If the user made a local commit, the short hash becomes useless.

> For users it would work even better than svn revision.
> For devs or users who do commit locally both svn and git "revisions"
> can be "spoofed" anyway so it just useless.
It's not about whether they can be spoofed or not. Users typically don't
spoof revisions because that would be a stupid and far fetched thing to
do when reporting a bug.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Bruno Randolf]

On 10/11/2015 01:48 PM, John Crispin wrote:
> although i see the point, out of tree fork have never been relevant to
> any core decision makings

I understand that this is not the main concern for core OpenWRT
developers, but on the other hand you must be aware that there exist
several of these "forks" which carry project or vendor specific changes,
stuff that can't be made OpenWRT trunk compatible, or not yet, or only
in parts, etc... and making it easier for these "forks" to merge OpenWRT
releases also makes it easier to merge project specific improvements
back to OpenWRT trunk. Otherwise these "forks" stay real forks, which
branch off at some revision and never merge again. That's why I think it
would be good for OpenWRT to allow easier merging in all directions.

Apart from that of course, the OpenWRT core developers are a pretty
small team, and a centralized model may fit them well, especially if
they don't want to include more people in the process. The decision is
up to the core developers.

bruno
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Javier Domingo Cansino]

>
> I haven't seen a single instance of somebody doing this, and in my
> opinion it would be kind of stupid anyway :)
> We don't even advertise the SVN server URL to users anymore for a reason.
>

This was a way to demonstrate that the forking point is not actually a
problem SVN solves. Not having a similar revision number that collides with
the one used in official repo is now sustained by the fact that you are the
only ones using SVN.

And you think users will actually do that? Based on previous experience,
> I really don't. The way it's set up right now, people can fork as they
> wish and the scripts automatically determining the OpenWrt base version
> will just work.
>
That's the work that needs to be done, although there are plenty forks over
there with a solution to that. I have seen them at least, but I can't
provide code :(, so if someone has a solution that can share, shall
intervene here.

It's not about what you theoretically can do, it's about what users will
> end up doing.
>
That doesn't affect your workflow. At the end you will have the same
problems as you have now because people is already using git to interact
with openwrt. They provide a forking base, and there you go.


> Wow, now you're making it really confusing for everybody involved. Some
> changes live in an external git repo, some changes live as patches, and
> whenever the external repo changes we're supposed to update the revision
> in the OpenWrt tree?
>

I am really sorry but I haven't worked enough with the kernel part as to
say how maintainable would this solution be. I was just giving another
alternative to submodules.

Just in case, my advice here was not to use submodules. It was just a git
advice rather than an openwrt git based advice.


> I haven't seen any proposal that deals with the revision crafting issue
> in a practical and useful way. I also haven't seen many compelling
> arguments about what the practical benefit of these changes would be.
>
> I see repeated claims that assume that having patches in a git repo will
> make it easier to upstream stuff, and I just don't believe those claims
> without a proper explanation.
>
I find this paragraph confusing because I don't really know if you are
referring to the kernel in openwrt, or to openwrt as a whole.

In the first case, I just want to say that it is possible to work with
submodules, but it costs you brain-cpu to do it correctly most of the
times. That's why my advice against submodules. I can further expand if
someone wants to know which solutions I have seen correctly working.

In the second case, from what I do, I would find much easier to have a git
based openwrt, not for git itself (I am already using it), but for the
tools (step 2) and workflows you can have. I expand this below.


> Before you try to convince us to change the workflow, I would really
> like to see a *detailed* explanation of how this would actually help us.
> If you really believe that this would be a good fit, then you will have
> to be a lot more specific about the potential benefits.
>

The benefits of the openwrt git based developing are the next ones, based
on previous experience, using Github as a model, similar applies to Gitlab:
 - Easier to get started with openwrt trivial contributions. If I find a
typo, I can directly from the web interface fork, change and PR to the main
repo.
 - Easier tracking of the status of my patch, the issues I have submitted
and the pending work. This is mostly because UIs/workflows are pretty
complete.
 - Easier way to update my patch, less noise to the list. I always get it
wrong, and resubmitting when it is just some formatting issues is far less
noisy. With github/gitlab, I just have to checkout the branch I am sending
my patch from and do whatever I need to make it
openwrt-contribution-guidelines compliant.
 - Review of my patches. I can actually track if I have done everything
needed to get my patch accepted. Past day I submitted a simple patch to
libubox and I forgot to reorder variable declarations. Also, more clear,
non mailbox dependant patch review, In a glance I can see my patch, the
comments it has, and the conversation about specific lines, even if I am
not suscribed.
 - More user friendly. I know this might not be important for some people,
but most of the users out there willing to help, although not excelent
devs, may be able to help if they have tons of tutorials on how to use the
web interface.
 - Of course, you still can do everything as you already do, you checkout
the branch from the PR and commit it manually, and github/gitlab will
detect you merged that commit and will close the PR.

As you see, these are mostly user experience improvements. Maybe for you
make no difference at all while core developing, but I find those benefits
really worthy. I have seen others state some of them too.

Just to finish, I think this conversion from svn to git doesn't have as
main objective to make your life as core devs easier although it will

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 16:20, Javier Domingo Cansino wrote:
> I haven't seen a single instance of somebody doing this, and in my
> opinion it would be kind of stupid anyway :)
> We don't even advertise the SVN server URL to users anymore for a
> reason.
> 
> 
> This was a way to demonstrate that the forking point is not actually a
> problem SVN solves. Not having a similar revision number that collides
> with the one used in official repo is now sustained by the fact that you
> are the only ones using SVN.
Please don't try to argue with me based on unlikely hypothetical
scenarios of what somebody could do (but never does). I'm interested in
stuff that works in practice.

> And you think users will actually do that? Based on previous experience,
> I really don't. The way it's set up right now, people can fork as they
> wish and the scripts automatically determining the OpenWrt base version
> will just work.
> 
> That's the work that needs to be done, although there are plenty forks
> over there with a solution to that. I have seen them at least, but I
> can't provide code :(, so if someone has a solution that can share,
> shall intervene here.
I have yet to see an approach for this that actually works and deals
with all the common scenarios where people fork OpenWrt and make a few
local changes.

> It's not about what you theoretically can do, it's about what users will
> end up doing.
> 
> That doesn't affect your workflow. At the end you will have the same
> problems as you have now because people is already using git to interact
> with openwrt. They provide a forking base, and there you go.
What users end up doing DOES affect our workflow. If asking users to
provide version information from stuff running on their routers gets
more complicated because local commits might obscure the revision hash,
then that creates more work for us devs.

> Wow, now you're making it really confusing for everybody involved. Some
> changes live in an external git repo, some changes live as patches, and
> whenever the external repo changes we're supposed to update the revision
> in the OpenWrt tree?
> 
> 
> I am really sorry but I haven't worked enough with the kernel part as to
> say how maintainable would this solution be. I was just giving another
> alternative to submodules.
> 
> Just in case, my advice here was not to use submodules. It was just a
> git advice rather than an openwrt git based advice. 
And I've actually given much thought to the cost and benefits of our
current workflow vs doing it in git. My main problem is not with the
part of submodules vs external stuff, it's with the workflow of
maintaining our kernel changes in a git repo directly instead of having
patches.

> I haven't seen any proposal that deals with the revision crafting issue
> in a practical and useful way. I also haven't seen many compelling
> arguments about what the practical benefit of these changes would be.
> 
> I see repeated claims that assume that having patches in a git repo will
> make it easier to upstream stuff, and I just don't believe those claims
> without a proper explanation.
> 
> I find this paragraph confusing because I don't really know if you are
> referring to the kernel in openwrt, or to openwrt as a whole.
This was referring to having the openwrt kernel stuff in git.

> In the first case, I just want to say that it is possible to work with
> submodules, but it costs you brain-cpu to do it correctly most of the
> times. That's why my advice against submodules. I can further expand if
> someone wants to know which solutions I have seen correctly working.
> 
> In the second case, from what I do, I would find much easier to have a
> git based openwrt, not for git itself (I am already using it), but for
> the tools (step 2) and workflows you can have. I expand this below.
>  
> 
> Before you try to convince us to change the workflow, I would really
> like to see a *detailed* explanation of how this would actually help us.
> If you really believe that this would be a good fit, then you will have
> to be a lot more specific about the potential benefits.
> 
> 
> The benefits of the openwrt git based developing are the next ones,
> based on previous experience, using Github as a model, similar applies
> to Gitlab:
>  - Easier to get started with openwrt trivial contributions. If I find a
> typo, I can directly from the web interface fork, change and PR to the
> main repo.
Typo fixes are the least relevant changes. Making it easier to do that
kind of change is not a priority, especially if other things are made worse.

>  - Easier tracking of the status of my patch, the issues I have
> submitted and the pending work. This is mostly because UIs/workflows are
> pretty complete.
We have patchwork for tracking submissions, and people get notified when
their patches are accepted or rejected.

>  - Easier way to update my patch, less noise to the 

Re: [OpenWrt-Devel] SVN to GIT transition

[Jonathan Bennett]

On Mon, Oct 12, 2015 at 2:11 PM David Lang  wrote:

> On Mon, 12 Oct 2015, Felix Fietkau wrote:
>
> > On 2015-10-12 16:11, Roman Yeryomin wrote:
> >> On 12 October 2015 at 16:34, Felix Fietkau  wrote:
> >>> On 2015-10-12 15:09, Javier Domingo Cansino wrote:
>  Right now, the revision number (r) is really useful to
> figure
>  out what particular openwrt version is being used, when people
> report
>  bugs. The commit hash cannot be used as a replacement, since it
> might be
>  one that isn't present in the official repo.
>  When using tags as a starting point (via git describe), somebody
> has to
>  create those tags, which is cumbersome (and would mean adding
> lots of
>  useless ones).
> 
>  The tags would be the major versions and RCs. I don't believe other
> tags
>  should be used.
> 
>  Apart from that, I understand that if someone cloned the SVN repo
> (full
>  svn history), created it's own server, and developed on top of a given
>  revision X, the same problem would arise.
> >>> I haven't seen a single instance of somebody doing this, and in my
> >>> opinion it would be kind of stupid anyway :)
> >>> We don't even advertise the SVN server URL to users anymore for a
> reason.
> >>>
> >>
> >> IMO git describe --dirty would work perfectly. You would see a short
> >> hash and if user modified it or not.
> > If the user made a local commit, the short hash becomes useless.
>
> if the user does a SVN checkout and then modifies things, the r is
> also
> not valid (although it does give you an idea where things branched)
>
> David Lang

His point is that users don't ever do an SVN checkout. Because the r number
is baked into the image, it's a really easy and obvious way for an end user
to report the revision in a bug report.  I can see the advantage in this.
If we are to move to git, we would want some way to preserve this feature,
that is a super easy way for a user to report the revision.  We could bake
the short hash into the image, but this would not be useful if any commits
were added locally, whereas the r number would still show some useful
information.

Would it be possible to track the revision number in an automated way even
in a git repo?  So store the r number, and automatically increment on
commits.  Not sure if that's an option, but it seems like it might address
the problem.

--Jonathan Bennett
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 22:06, David Lang wrote:
> On Mon, 12 Oct 2015, Jonathan Bennett wrote:
> 
>> His point is that users don't ever do an SVN checkout. Because the r number
>> is baked into the image, it's a really easy and obvious way for an end user
>> to report the revision in a bug report.  I can see the advantage in this.
>> If we are to move to git, we would want some way to preserve this feature,
>> that is a super easy way for a user to report the revision.  We could bake
>> the short hash into the image, but this would not be useful if any commits
>> were added locally, whereas the r number would still show some useful
>> information.
>>
>> Would it be possible to track the revision number in an automated way even
>> in a git repo?  So store the r number, and automatically increment on
>> commits.  Not sure if that's an option, but it seems like it might address
>> the problem.
> 
> It sounds like what you really want to do is to have the nightly build embed 
> the 
> date of the build in the image and have people report that.
Many people build from source and don't use nightly builds.

> If someone checks out the source and compiles a new copy (with local 
> modifications), reporting a SVN version is as misleading as a git hash.
It may not always be accurate, but the SVN version is actually useful in
most cases, even when modifications are present.

> I know that various projects I work with have the build process embed the 
> date 
> in the package versions, so it should be straightforward to put it into some 
> file in the resulting firmware image. Such a process can also check if it's 
> running on the 'official' tree or in someone else's repo (check repo 
> owner/e-mail) and add the initials of the person compiling it.
What I don't understand is how the script should check if something is
the official tree, e.g. in the simple case of somebody having forked the
OpenWrt mirror on github, cloned it locally, added and pushed a few
commits and then made a build.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[David Lang]

On Mon, 12 Oct 2015, Felix Fietkau wrote:


On 2015-10-12 22:06, David Lang wrote:

On Mon, 12 Oct 2015, Jonathan Bennett wrote:


His point is that users don't ever do an SVN checkout. Because the r number
is baked into the image, it's a really easy and obvious way for an end user
to report the revision in a bug report.  I can see the advantage in this.
If we are to move to git, we would want some way to preserve this feature,
that is a super easy way for a user to report the revision.  We could bake
the short hash into the image, but this would not be useful if any commits
were added locally, whereas the r number would still show some useful
information.

Would it be possible to track the revision number in an automated way even
in a git repo?  So store the r number, and automatically increment on
commits.  Not sure if that's an option, but it seems like it might address
the problem.


It sounds like what you really want to do is to have the nightly build embed the
date of the build in the image and have people report that.

Many people build from source and don't use nightly builds.


If someone checks out the source and compiles a new copy (with local
modifications), reporting a SVN version is as misleading as a git hash.

It may not always be accurate, but the SVN version is actually useful in
most cases, even when modifications are present.


I know that various projects I work with have the build process embed the date
in the package versions, so it should be straightforward to put it into some
file in the resulting firmware image. Such a process can also check if it's
running on the 'official' tree or in someone else's repo (check repo
owner/e-mail) and add the initials of the person compiling it.


What I don't understand is how the script should check if something is
the official tree, e.g. in the simple case of somebody having forked the
OpenWrt mirror on github, cloned it locally, added and pushed a few
commits and then made a build.


git config --get user.name
git config --get user.email

if they are set to the name of the official buildbot, no nothing. If they are 
set to anything else, take some data (initials or something) and make that part 
of the version number.


It's not checking if it's an unmodified tree, just if it's being built on the 
OpenWRT infrastructure.


If someone is building an unmodified tree, the git hash will work for 
identifying what tree it is. And someone else posted a process for trackign 
divergence from the upstream tree if they are modifying it first.


David Lang
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[David Lang]

On Mon, 12 Oct 2015, Felix Fietkau wrote:


On 2015-10-12 22:02, Javier Domingo Cansino wrote:

Would it be possible to track the revision number in an automated
way even in a git repo?  So store the r number, and automatically
increment on commits.  Not sure if that's an option, but it seems
like it might address the problem.


In git you wouldn't need such thing, the way would be to track the
forking point comparing the user history with the upstream master
history, and describing the path. The oneliner I sent before (which I
now realize I split in two), did (or will do) the following.

1) Go back in history and find the latest tag, save it as $tag

We currently don't have any tags for mainline trunk, since we usually
don't directly release from it.


I would put a nightly tag in place (tags are pretty cheap)


2) Find the forking point between upstream and user branch if any, save
current commit if not such fork exists as $parent.

How does the script know which one is the right upstream?


git knows where it was cloned from, so it knows what upstream is for any local 
branch.



3) count how many commits are from $tag commit to $parent commit, save
it as $parent_n
3) If fork exists, count how many commits from $parent to HEAD, save it
as $commit_n
4) If tree is dirty, save $dirty='-dirty', else $dirty=''

compose the build version info as the following:

$tag-$parent_n-$parent-$commit_n-$parent$dirty

If I see such a string, how do I look up the last OpenWrt commit from
that? With the revision number, I simply start git log and search for
@


if you make a nightly/weekly tag it becomes trivial to lookup. you can also use 
the first 6/8 characters of the git commit and look that up (or git log 
12345678..HEAD to show everything between that commit and the current head)


David Lang
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Michael Büsch]

On Mon, 12 Oct 2015 14:04:09 +0200
Felix Fietkau  wrote:

> If we do everything in git, we either have to constantly remember to tag
> revisions,

Only some milestones would have to be tagged on a regular basis. This
could even be done automatically with a daily tag or such.
git describe will do the rest. It will do even more than svn revisions,
because it includes (part of) the hash.

-- 
Michael


pgpnElG2SDkAc.pgp
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 22:28, David Lang wrote:
> On Mon, 12 Oct 2015, Felix Fietkau wrote:
> 
>> On 2015-10-12 22:02, Javier Domingo Cansino wrote:
>>> Would it be possible to track the revision number in an automated
>>> way even in a git repo?  So store the r number, and automatically
>>> increment on commits.  Not sure if that's an option, but it seems
>>> like it might address the problem.
>>>
>>>
>>> In git you wouldn't need such thing, the way would be to track the
>>> forking point comparing the user history with the upstream master
>>> history, and describing the path. The oneliner I sent before (which I
>>> now realize I split in two), did (or will do) the following.
>>>
>>> 1) Go back in history and find the latest tag, save it as $tag
>> We currently don't have any tags for mainline trunk, since we usually
>> don't directly release from it.
> 
> I would put a nightly tag in place (tags are pretty cheap)
Sounds nasty.

>>> 2) Find the forking point between upstream and user branch if any, save
>>> current commit if not such fork exists as $parent.
>> How does the script know which one is the right upstream?
> 
> git knows where it was cloned from, so it knows what upstream is for any 
> local 
> branch.
Yeah, but where it was cloned from might not be OpenWrt upstream.

>>> 3) count how many commits are from $tag commit to $parent commit, save
>>> it as $parent_n
>>> 3) If fork exists, count how many commits from $parent to HEAD, save it
>>> as $commit_n
>>> 4) If tree is dirty, save $dirty='-dirty', else $dirty=''
>>>
>>> compose the build version info as the following:
>>>
>>> $tag-$parent_n-$parent-$commit_n-$parent$dirty
>> If I see such a string, how do I look up the last OpenWrt commit from
>> that? With the revision number, I simply start git log and search for
>> @
> 
> if you make a nightly/weekly tag it becomes trivial to lookup. you can also 
> use 
> the first 6/8 characters of the git commit and look that up (or git log 
> 12345678..HEAD to show everything between that commit and the current head)
The lookup only works if the tags were carried over as well. Not sure if
that's the case when somebody does a github fork of the mirror repo.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Javier Domingo Cansino]

>
> We currently don't have any tags for mainline trunk, since we usually
> don't directly release from it.
>

I would like to know how you usually release. Can you map a commit to a
release, if you can't, then we may use another simpler method.

$parent-$commit$dirty

That would give you info enought to checkout either the $parent, if you
don't have access to $commit, and to know that something was changed in
$commit.


> How does the script know which one is the right upstream?
>
It's hardcoded in the version script. If remote doesn't exist, I can inject
it temporarily, bad thing is that I would need to fetch upstream to be able
to compare AFAIK. If the remote does exist, I can just generate it from
there (don't need to have latest commit to know where they forked)


> If I see such a string, how do I look up the last OpenWrt commit from
> that? With the revision number, I simply start git log and search for
> @
>
The number of commits are just for people that comes from SVN to feel
comfortable. You don't really need them. You can have the number of
previous commits if you wish, but is not needed really (it might be an
indicative on how much work there is)

We could do fancy things like instead of logging the number of commits, log
the number of diff lines.

$parent-$commit-$difflines$dirty.

However I find this rather disturbing and even privacy compromising.

I think I could provide the proper solution if you tell me what you thing
would be useful for you to have.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 22:19, David Lang wrote:
> On Mon, 12 Oct 2015, Felix Fietkau wrote:
> 
>> On 2015-10-12 22:06, David Lang wrote:
>>> On Mon, 12 Oct 2015, Jonathan Bennett wrote:
>>>
 His point is that users don't ever do an SVN checkout. Because the r number
 is baked into the image, it's a really easy and obvious way for an end user
 to report the revision in a bug report.  I can see the advantage in this.
 If we are to move to git, we would want some way to preserve this feature,
 that is a super easy way for a user to report the revision.  We could bake
 the short hash into the image, but this would not be useful if any commits
 were added locally, whereas the r number would still show some useful
 information.

 Would it be possible to track the revision number in an automated way even
 in a git repo?  So store the r number, and automatically increment on
 commits.  Not sure if that's an option, but it seems like it might address
 the problem.
>>>
>>> It sounds like what you really want to do is to have the nightly build 
>>> embed the
>>> date of the build in the image and have people report that.
>> Many people build from source and don't use nightly builds.
>>
>>> If someone checks out the source and compiles a new copy (with local
>>> modifications), reporting a SVN version is as misleading as a git hash.
>> It may not always be accurate, but the SVN version is actually useful in
>> most cases, even when modifications are present.
>>
>>> I know that various projects I work with have the build process embed the 
>>> date
>>> in the package versions, so it should be straightforward to put it into some
>>> file in the resulting firmware image. Such a process can also check if it's
>>> running on the 'official' tree or in someone else's repo (check repo
>>> owner/e-mail) and add the initials of the person compiling it.
>>
>> What I don't understand is how the script should check if something is
>> the official tree, e.g. in the simple case of somebody having forked the
>> OpenWrt mirror on github, cloned it locally, added and pushed a few
>> commits and then made a build.
> 
> git config --get user.name
> git config --get user.email
> 
> if they are set to the name of the official buildbot, no nothing. If they are 
> set to anything else, take some data (initials or something) and make that 
> part 
> of the version number.
> 
> It's not checking if it's an unmodified tree, just if it's being built on the 
> OpenWRT infrastructure.
> 
> If someone is building an unmodified tree, the git hash will work for 
> identifying what tree it is. And someone else posted a process for trackign 
> divergence from the upstream tree if they are modifying it first.
I still have doubts about that process. And why should the version info
be treated differently if things are built on the official infrastructure?

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[David Lang]

On Mon, 12 Oct 2015, Felix Fietkau wrote:


On 2015-10-12 22:28, David Lang wrote:

On Mon, 12 Oct 2015, Felix Fietkau wrote:


On 2015-10-12 22:02, Javier Domingo Cansino wrote:

Would it be possible to track the revision number in an automated
way even in a git repo?  So store the r number, and automatically
increment on commits.  Not sure if that's an option, but it seems
like it might address the problem.


In git you wouldn't need such thing, the way would be to track the
forking point comparing the user history with the upstream master
history, and describing the path. The oneliner I sent before (which I
now realize I split in two), did (or will do) the following.

1) Go back in history and find the latest tag, save it as $tag

We currently don't have any tags for mainline trunk, since we usually
don't directly release from it.


I would put a nightly tag in place (tags are pretty cheap)

Sounds nasty.


why?


2) Find the forking point between upstream and user branch if any, save
current commit if not such fork exists as $parent.

How does the script know which one is the right upstream?


git knows where it was cloned from, so it knows what upstream is for any local
branch.

Yeah, but where it was cloned from might not be OpenWrt upstream.


true, but if you work from tags, it can just look for the difference since the 
most recent tag (or even the most recent tag that matches a specific pattern)



3) count how many commits are from $tag commit to $parent commit, save
it as $parent_n
3) If fork exists, count how many commits from $parent to HEAD, save it
as $commit_n
4) If tree is dirty, save $dirty='-dirty', else $dirty=''

compose the build version info as the following:

$tag-$parent_n-$parent-$commit_n-$parent$dirty

If I see such a string, how do I look up the last OpenWrt commit from
that? With the revision number, I simply start git log and search for
@


if you make a nightly/weekly tag it becomes trivial to lookup. you can also use
the first 6/8 characters of the git commit and look that up (or git log
12345678..HEAD to show everything between that commit and the current head)

The lookup only works if the tags were carried over as well. Not sure if
that's the case when somebody does a github fork of the mirror repo.


tags are carried over in just about all cases (github does so by default, 
while there are manual ways to not get them, that will cause people other 
problems), commit hashes are an intrinsic part of the repo.


David Lang
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Javier Domingo Cansino]

>
> I have yet to see an approach for this that actually works and deals
>
with all the common scenarios where people fork OpenWrt and make a few
> local changes.
>
I see I have not enough information on what are the common use cases. For
me, these are the following:
 - User clones openwrt master, makes some work on it and has an issue.
 - Company uses openwrt release as base.
 - Company uses openwrt random commit as base.

Supposing these are the use cases you want to support, please expand if
needed, I can develop a mini script that would check upstream for the
latest commit, and give you a version information string like the one I
showed. Please tell if you want any more information there.


> And I've actually given much thought to the cost and benefits of our
> current workflow vs doing it in git. My main problem is not with the
> part of submodules vs external stuff, it's with the workflow of
> maintaining our kernel changes in a git repo directly instead of having
> patches.


I have to agree that I find pretty clean the current method, although it
can be difficult to with it develop, I understand makes it easier to
maintain it.

However, I am not willing to discuss whether to change the current kernel
patch system to a git branch releases based one, because I haven't used it
enough.

Typo fixes are the least relevant changes. Making it easier to do that
>
kind of change is not a priority, especially if other things are made worse.
>
Let's hope we don't make things worse but different, which might seem worse
at the beginning in comparison to the workflow you have been long
accustomed to.


> We have patchwork for tracking submissions, and people get notified when
> their patches are accepted or rejected.

The interface is not as clean as the github/gitlab one. And people is more
relaxed with responsive and intuitive interfaces.

Less work for the submitter, but more work for testing before
> commit/push => not a good trade-off on my opinion.
>
Let's not make it worse for the tester/committer.

I personally find the pull request workflow very cumbersome. With what
> we have now, I can just 'git am' the ones that look sane, do a final
> test build + review, and then 'git svn dcommit' the result.
> With pull requests, I'd have to take those in a private branch or
> something, then run git pull on my local machine before being able to
> test stuff. Also, this will spam the repo history with annoying merge
> commits unless I do a rebase myself.
>

I can prepare a tool that just cherry-picks changes from the PR so that you
can test them easily. You can also ask the contributor to change the shape
of the commits, and the tool would then replicate again the changes on top
of HEAD.

For the core repo, I'd rather have higher patch quality instead of more
> contributions.
>
I can't make quality better just with git, but we could introduce travis-ci
for basic testing of PRs, to report basic failures that might have slipped
off the contributor (this would come later).

This way my patch from the other day wouldn't have needed to be reviewed
until check-patch had run on it.


> The main bottleneck in core development is not users submitting patches,
> it's patch review and especially testing. In my opinion your suggestions
> make that part harder.
>
With the tools I can create I hope it will be easier to do this, also
because issues and PRs have unique IDs, we could refer to them and make
testing much more controlled. For example, using travis-ci for PRs.


> The work done by core devs is the main bottleneck, so I care about that
> a lot more than making the life of drive-by contributors easier.
>

I agree that the bottlenecks should be reduced. I think I have spotted some
ways we could make a little better these.

I think gitlab/github is a really good choice because if everything in the
development (the repo and the PRs) is done using the same tool, we can have
nice features to help you reduce the bottleneck.

I would love to sort of arrange a trial period to have experience on how
you feel the tools, what command line helpers you would need and overall
feedback on the process to make the tools more adapted to your need.

I believe we should for now concentrate on steps 1-2), git based main repo,
hosted in a service such as gitlab/github.

I can prepare a sample repo where you could interact with a contributor,
not by means of everyone sending stuff to core through there but just a few
during some days.

If you want, before doing this, I can develop the two command lines I spoke
about, so that you can generate the build version info and the
cherrypick/patch checkout tool.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Javier Domingo Cansino]

>
> Would it be possible to track the revision number in an automated way even
> in a git repo?  So store the r number, and automatically increment on
> commits.  Not sure if that's an option, but it seems like it might address
> the problem.
>

In git you wouldn't need such thing, the way would be to track the forking
point comparing the user history with the upstream master history, and
describing the path. The oneliner I sent before (which I now realize I
split in two), did (or will do) the following.

1) Go back in history and find the latest tag, save it as $tag
2) Find the forking point between upstream and user branch if any, save
current commit if not such fork exists as $parent.
3) count how many commits are from $tag commit to $parent commit, save it
as $parent_n
3) If fork exists, count how many commits from $parent to HEAD, save it as
$commit_n
4) If tree is dirty, save $dirty='-dirty', else $dirty=''

compose the build version info as the following:

$tag-$parent_n-$parent-$commit_n-$parent$dirty
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[David Lang]

On Mon, 12 Oct 2015, Jonathan Bennett wrote:


His point is that users don't ever do an SVN checkout. Because the r number
is baked into the image, it's a really easy and obvious way for an end user
to report the revision in a bug report.  I can see the advantage in this.
If we are to move to git, we would want some way to preserve this feature,
that is a super easy way for a user to report the revision.  We could bake
the short hash into the image, but this would not be useful if any commits
were added locally, whereas the r number would still show some useful
information.

Would it be possible to track the revision number in an automated way even
in a git repo?  So store the r number, and automatically increment on
commits.  Not sure if that's an option, but it seems like it might address
the problem.


It sounds like what you really want to do is to have the nightly build embed the 
date of the build in the image and have people report that.


If someone checks out the source and compiles a new copy (with local 
modifications), reporting a SVN version is as misleading as a git hash.


I know that various projects I work with have the build process embed the date 
in the package versions, so it should be straightforward to put it into some 
file in the resulting firmware image. Such a process can also check if it's 
running on the 'official' tree or in someone else's repo (check repo 
owner/e-mail) and add the initials of the person compiling it.


then something like the -dirty info that was mentioned earlier could also be 
embedded to show the development since it branched from the main OpenWRT repo.


David Lang
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 16:47, Javier Domingo Cansino wrote:
> Many people follow current trunk, and we need to have precise version
> information for that when they report a bug. We don't want to regularly
> tag stuff just to keep reported version information up to date.
> 
> 
> This is already done using --dirty. I generates all the information you
> need.
> 
> You can generate whatever information you wish. For example, if total
> trazability of the user is what you want:
> base=$(git merge-base github/master HEAD)
> echo $(git describe --tags $base)-$(git log --oneline $base..HEAD | wc
> -l)-$(git log --oneline | head -n1 | cut -c-8)
> 
> That would give you v1.0-rc1-5-gd66a89f-4-9f0e84a -> base tag, commit
> count from the base to the forking commit, hash of that commit, number
> of commits since fork, hash of the commit.
> 
> You could even add a -dirty if you wish to to tell you if that 4th
> commit after the fork has been compiled cleanly or not.
But that assumes a specific remote in the git config pointing towards
the main openwrt repo. If somebody forked the OpenWrt mirror on github,
the appropriate remote will not be present automatically, and the above
approach will fail.
What we have now is robust against that sort of thing.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 22:02, Javier Domingo Cansino wrote:
> Would it be possible to track the revision number in an automated
> way even in a git repo?  So store the r number, and automatically
> increment on commits.  Not sure if that's an option, but it seems
> like it might address the problem.
> 
> 
> In git you wouldn't need such thing, the way would be to track the
> forking point comparing the user history with the upstream master
> history, and describing the path. The oneliner I sent before (which I
> now realize I split in two), did (or will do) the following.
> 
> 1) Go back in history and find the latest tag, save it as $tag
We currently don't have any tags for mainline trunk, since we usually
don't directly release from it.

> 2) Find the forking point between upstream and user branch if any, save
> current commit if not such fork exists as $parent.
How does the script know which one is the right upstream?

> 3) count how many commits are from $tag commit to $parent commit, save
> it as $parent_n
> 3) If fork exists, count how many commits from $parent to HEAD, save it
> as $commit_n
> 4) If tree is dirty, save $dirty='-dirty', else $dirty=''
> 
> compose the build version info as the following:
> 
> $tag-$parent_n-$parent-$commit_n-$parent$dirty
If I see such a string, how do I look up the last OpenWrt commit from
that? With the revision number, I simply start git log and search for
@

- felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Javier Domingo Cansino]

So the questions to be answered to provide a build version string are.

- Are you planning to use git tags for something? What are you needs for it?
- What information would you like to have from the build?

Examples: last upstream common commit, current commit, dirtiness,
officialness.

Also, I am looking that you are speaking about nightly tags, I wouldn't
recommend at all having those kind of tags. Nightly tags for build version
string would loose all the meaning, if you intend the build version to be
universal. It all depends on your answers to those two questions
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 23:18, Bruno Randolf wrote:
> On 10/12/2015 03:22 PM, Felix Fietkau wrote:
 When using tags as a starting point (via git describe), somebody has to
 create those tags, which is cumbersome (and would mean adding lots of
 useless ones).
>>>
>>> What's cumbersome? And why would you have to create useless tags?
>>>
>> Many people follow current trunk, and we need to have precise version
>> information for that when they report a bug. We don't want to regularly
>> tag stuff just to keep reported version information up to date.
> 
> You don't need to. Try this in your OpenWRT trunk git repo:
> 
> git tag -a r 753606a51c979440e10771f0d11494b7b7c1eac2
> 
> (Tagging the very first commit with "r".)
> 
> Now do:
> 
> git describe
> 
> r-35387-g83c5a41
> 
> If you prefer, cut the last part and get "r-35387".
> 
> Looks familiar? Now you even have real linear numbering in each branch,
> without the gaps you get when committing to different branches in SVN +
> the unique hash. Need to look up the commit? Use the hash (g83c5a41).
> 
> Of course "r" is just an example to show the familiarity with SVN
> revisions, you could choose whatever seems fit, for example at this
> moment it would make sense to tag the moment when 15.05 was branched off
> from trunk as "dd", then you'd get "dd-number-hash" in trunk and
> "15.05-66-g66620f5" in the 15.05 branch (you actually do, just need to
> use "git describe --tags" because the tag was not created with -a).
That looks quite interesting. The issue I see with that is if somebody
adds a local commit on top and builds the tree, the number behind 'r' is
misleading and the hash is useless.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[John Crispin]

On 11/10/2015 14:09, Jan Čermák wrote:
> Hello,
> 
> thanks for pointing that out, Steven. Yes, this is basically the main reason 
> why
> Bedrich opened this topic. If you need to maintain sustainable OpenWrt fork 
> (no
> flame please, there are some situations - like running "heavyweight" OpenWrt
> fork on a device like our Turris - when it's reasonable to fork), pure Git is
> the way to go.

although i see the point, out of tree fork have never been relevant to
any core decision makings


> When you have a fork based on some trunk version, it's not *that hard* to 
> merge
> upstream changes from time to time, but if you want to base your system on 
> some
> stable branch and then upgrade to a newer one, getting back the history of
> changes between versions gets pretty awkward.

indeed



> IMHO the main argument against Git over SVN here is that users would lose the
> information that'll help them to compare which version is newer. But as Atilla
> and Bruno said - git describe works maybe even better than just an 
> incrementing
> revision number. Maybe it'd be needed to change a some of the workflow, but 
> the
> pros of git (for us mainly: keeping the track of history and merging upstream
> changes) outweigh the cons.

essentially the same point as above


> Last but not least - Git has become a de-facto standard for larger projects 
> with
> more contributors and the it helps to open the project to community - sending 
> a
> patch to the mailing list (a patch that sometimes just lies there without any
> positive nor negative response for weeks) might discourage smaller 
> contributors.
> Just look at the situation of openwrt-packages - the people became much more
> active since moving the repo to GitHub.

patches will linger in mailing list until someone has time to look at
them. the version control system used is completely irrelevant


to sum up, people want to have the history inside the branches ?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Jan Čermák]

Hello,

thanks for pointing that out, Steven. Yes, this is basically the main reason why
Bedrich opened this topic. If you need to maintain sustainable OpenWrt fork (no
flame please, there are some situations - like running "heavyweight" OpenWrt
fork on a device like our Turris - when it's reasonable to fork), pure Git is
the way to go.

When you have a fork based on some trunk version, it's not *that hard* to merge
upstream changes from time to time, but if you want to base your system on some
stable branch and then upgrade to a newer one, getting back the history of
changes between versions gets pretty awkward.

IMHO the main argument against Git over SVN here is that users would lose the
information that'll help them to compare which version is newer. But as Atilla
and Bruno said - git describe works maybe even better than just an incrementing
revision number. Maybe it'd be needed to change a some of the workflow, but the
pros of git (for us mainly: keeping the track of history and merging upstream
changes) outweigh the cons.

Last but not least - Git has become a de-facto standard for larger projects with
more contributors and the it helps to open the project to community - sending a
patch to the mailing list (a patch that sometimes just lies there without any
positive nor negative response for weeks) might discourage smaller contributors.
Just look at the situation of openwrt-packages - the people became much more
active since moving the repo to GitHub.

Regards,
Jan

On 10.10.2015 15:21, Steven Barth wrote:
> One important point was IIRC, migrating from one stable branch to another is 
> awkward
> since the history is different, so rebasing custom changes on top is painful.
> 
> All in all there was relatively overwhelming feedback of most of the people 
> at the
> summit that there lifes would be very much easier if the main repo was based 
> on git
> and there was noone who really felt the opposite.
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Emmanuel Deloget]

Hello John,

On Sun, Oct 11, 2015 at 2:48 PM, John Crispin  wrote:
>
> On 11/10/2015 14:09, Jan Čermák wrote:
> > Hello,
> >
> > thanks for pointing that out, Steven. Yes, this is basically the main 
> > reason why
> > Bedrich opened this topic. If you need to maintain sustainable OpenWrt fork 
> > (no
> > flame please, there are some situations - like running "heavyweight" OpenWrt
> > fork on a device like our Turris - when it's reasonable to fork), pure Git 
> > is
> > the way to go.
>
> although i see the point, out of tree fork have never been relevant to
> any core decision makings

Well, if all your users are using git, it can become at least a bit relevant :)

> > When you have a fork based on some trunk version, it's not *that hard* to 
> > merge
> > upstream changes from time to time, but if you want to base your system on 
> > some
> > stable branch and then upgrade to a newer one, getting back the history of
> > changes between versions gets pretty awkward.
>
> indeed
>
> > IMHO the main argument against Git over SVN here is that users would lose 
> > the
> > information that'll help them to compare which version is newer. But as 
> > Atilla
> > and Bruno said - git describe works maybe even better than just an 
> > incrementing
> > revision number. Maybe it'd be needed to change a some of the workflow, but 
> > the
> > pros of git (for us mainly: keeping the track of history and merging 
> > upstream
> > changes) outweigh the cons.
>
> essentially the same point as above
>
> > Last but not least - Git has become a de-facto standard for larger projects 
> > with
> > more contributors and the it helps to open the project to community - 
> > sending a
> > patch to the mailing list (a patch that sometimes just lies there without 
> > any
> > positive nor negative response for weeks) might discourage smaller 
> > contributors.
> > Just look at the situation of openwrt-packages - the people became much more
> > active since moving the repo to GitHub.
>
> patches will linger in mailing list until someone has time to look at
> them. the version control system used is completely irrelevant

I'm not sure about that. Git offer the possibility to have
non-committer maintainers that
can take control of a large part of the tree (for example, a few specific mips
architectures). This will limit the burden on the committers which
would then take pull
requests from sub-maintainers. As a consequence, proposed patches may
arrive in the
main tree faster than today (where some patches lies on one ML for days or month
when noone has the time to review and commit them).

I might be wrong, but it seems to me that the OpenWRT community is
bigger than ever.
I've been following the project from some time now, and I feel there
is some traction here.
Changing the SCM now might help in the near future - where the number
of potential
contributors will outnumber the number of commiters by a far margin.
Changing to git
now will prevent svn to get in the way in the future.

> to sum up, people want to have the history inside the branches ?

Yes, for sure. The also want to create their own branch from an
existing branch and
merge some important changes that happened on the master branch - for example to
use a newer version of some particular package, or to apply a kernel
patch they need.
They want to know what was applied on a particular branch (because following the
ML is not something everybody has the time to do, unfortunately). OpenWRT is no
longer a small thing that people use on their own personnal router. Its also a
distribution that companies uses to build firmwares for their consumer
products (we
do that at SFR on the 9box). Following and integrating OpenWRT changes is part
of my day to day job, and I must admit that a correct git repository - with the
corresponding tagged releases and branches are present - would be immensly
helpful.

BR,

-- Emmanuel Deloget

(P.S. this mail represent my personnal views, not the view of my employer).
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Joris de Vries]

> On 11 Oct 2015, at 14:48, John Crispin  wrote:
> 
> patches will linger in mailing list until someone has time to look at
> them. the version control system used is completely irrelevant

Which is true enough if the switch just encompasses moving to another VCS. 
However, what has not been made explicit enough is that switching to git _and_ 
a git web interface like Github/Gitlab may make it easier to contribute. My 
understanding is that it would be much easier to test proposed changes as 
people can simply do a checkout on a pull request and run the proposed code. 
Currently (unless I am missing something which is unfortunately quite 
possible), one would have to manually insert the patches to test.

Someone said earlier that switching to github for the packages made a positive 
difference in contributions. I would like to see that supported by some 
numbers, or possibly a contributor can elaborate a bit on the process and 
whether they perceive any benefits. That way, the migration of the packages 
might show a practical use case in the context of this project and its 
workflows.

Joris___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[L. D. Pinney]

Just my 2-cents

IF it isn't BROKENplease DON'T fix it.



On Sun, Oct 11, 2015 at 1:26 PM, Nemesis  wrote:

> On 10/10/2015 07:45 PM, nemesis wrote:
>
> On Sat, 10 Oct 2015 00:41:24 +0300, Roman Yeryomin 
>   wrote:
>
> On 9 October 2015 at 21:22, Jo-Philipp Wich 
>  wrote:
>
> Hi.
>
> Moving to Git seemed to have lots of traction at the summit, and I'll
> add my voice that this sounds like a step in the right direction for
> OpenWrt.  I'm assuming that we would want to do a proper SVN to Git
> conversion, and Eric's help on this would be great, I think.  My
> discussion with Eric is over on Google+ and marked public:
> https://plus.google.com/+JonathanBennett87/posts/bMPMjn7ZcJS
>
>
> Why does the core system need to migrate from svn to git?
>
>
> I thought everybody is using git anyway already. Are there people
> still using svn?
>
>
> doing something because everybody is doing so is not the best argument
> IMHO.
>
> I would say that using git would improve quite a few things:
>
> * it would be easier to send upstream patches
> * having a good git web interface like gitlab or github would allow
> newcomers to participate more easily
> * it would make life easier to the core contributors that prefer to work
> with git because git allows a very powerful development workflow compared
> to SVN
>
>
> I remember somebody also mentioned sending patches to the linux kernel
> would be easier.
>
> What do you people think about this point?
>
> Federico
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Jonathan Bennett]

Certain things are certainly broken.  The body of kernel code that OpenWrt
maintains (allows to bitrot) outside the upstream kernel tree is broken.

Regarding downstream forks, would using Git also make it easier for people
like project turris to push appropriate changes back into OpenWrt proper?

On Sun, Oct 11, 2015 at 1:38 PM L. D. Pinney  wrote:

> Just my 2-cents
>
> IF it isn't BROKENplease DON'T fix it.
>
>
>
> On Sun, Oct 11, 2015 at 1:26 PM, Nemesis  wrote:
>
>> On 10/10/2015 07:45 PM, nemesis wrote:
>>
>> On Sat, 10 Oct 2015 00:41:24 +0300, Roman Yeryomin
>>  
>> wrote:
>>
>> On 9 October 2015 at 21:22, Jo-Philipp Wich 
>>  wrote:
>>
>> Hi.
>>
>> Moving to Git seemed to have lots of traction at the summit, and I'll
>> add my voice that this sounds like a step in the right direction for
>> OpenWrt.  I'm assuming that we would want to do a proper SVN to Git
>> conversion, and Eric's help on this would be great, I think.  My
>> discussion with Eric is over on Google+ and marked public:
>> https://plus.google.com/+JonathanBennett87/posts/bMPMjn7ZcJS
>>
>>
>> Why does the core system need to migrate from svn to git?
>>
>>
>> I thought everybody is using git anyway already. Are there people
>> still using svn?
>>
>>
>> doing something because everybody is doing so is not the best argument
>> IMHO.
>>
>> I would say that using git would improve quite a few things:
>>
>> * it would be easier to send upstream patches
>> * having a good git web interface like gitlab or github would allow
>> newcomers to participate more easily
>> * it would make life easier to the core contributors that prefer to work
>> with git because git allows a very powerful development workflow compared
>> to SVN
>>
>>
>> I remember somebody also mentioned sending patches to the linux kernel
>> would be easier.
>>
>> What do you people think about this point?
>>
>> Federico
>>
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
>>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Jonathan Bennett]

On 11 Oct 2015, at 14:48, John Crispin  wrote:

patches will linger in mailing list until someone has time to look at
them. the version control system used is completely irrelevant

Which is true enough if the switch just encompasses moving to another VCS.
However, what has not been made explicit enough is that switching to git
_and_ a git web interface like Github/Gitlab may make it easier to
contribute. My understanding is that it would be much easier to test
proposed changes as people can simply do a checkout on a pull request and
run the proposed code. Currently (unless I am missing something which is
unfortunately quite possible), one would have to manually insert the
patches to test.

Someone said earlier that switching to github for the packages made a
positive difference in contributions. I would like to see that supported by
some numbers, or possibly a contributor can elaborate a bit on the process
and whether they perceive any benefits. That way, the migration of the
packages might show a practical use case in the context of this project and
its workflows.


I can comment on this last question.  I maintain fwknop, and before the
move of the third party packages to github, I had major issues trying to
get my patches committed.  The thing that was most frustrating is that I
was the maintainer for the package, and my patches that only touched that
package were not committed.  It was bad enough that I actually gave up and
wasn't doing anything related to OpenWrt development for over a year.

When the packages feed moved to github, I decided to come back and try
pushing patches again.  The experience has been much better.  I've had 24
hour turnarounds for many pull requests.  I think there are several factors
that led to such an improvement.  One is the easy interface to see changes
and the ability for someone with commit access to accept them so
trivially.  Expanding who has commit access to that repository has helped
as well.

Another big problem we see quite often is mangled patches in emails.  If
trivial patches could be pull requests instead of emails, it would lower
the noise level of mangled patches, and help new committers get their
patches in with less frustration.

Realistically, I think it's obvious that at some point we will have to move
away from SVN, if only because so many other projects are also doing so.
Because of the mass exodus from SVN, it seems destined to become legacy and
eventually unmaintained.  The sooner we commit to transitioning to git, and
start that transition, the easier it will be in the long run.

This brings another question to mind.  If we move to github/gitlab, do we
want to do bug tracking there as well, and retire trac altogether?

--Jonathan Bennett
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Nemesis]

On 10/10/2015 07:45 PM, nemesis wrote:
> On Sat, 10 Oct 2015 00:41:24 +0300, Roman Yeryomin
>  wrote:
>> On 9 October 2015 at 21:22, Jo-Philipp Wich  wrote:
>>> Hi.
>>>
 Moving to Git seemed to have lots of traction at the summit, and I'll
 add my voice that this sounds like a step in the right direction for
 OpenWrt.  I'm assuming that we would want to do a proper SVN to Git
 conversion, and Eric's help on this would be great, I think.  My
 discussion with Eric is over on Google+ and marked public:
 https://plus.google.com/+JonathanBennett87/posts/bMPMjn7ZcJS
>>>
>>> Why does the core system need to migrate from svn to git?
>>>
>>
>> I thought everybody is using git anyway already. Are there people
>> still using svn?
>
> doing something because everybody is doing so is not the best argument
> IMHO.
>
> I would say that using git would improve quite a few things:
>
> * it would be easier to send upstream patches
> * having a good git web interface like gitlab or github would allow
> newcomers to participate more easily
> * it would make life easier to the core contributors that prefer to
> work with git because git allows a very powerful development workflow
> compared to SVN

I remember somebody also mentioned sending patches to the linux kernel
would be easier.

What do you people think about this point?

Federico
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Attila Lendvai]

> Just my 2-cents
>
> IF it isn't BROKENplease DON'T fix it.


the question here is: how much time coders (maintainers, contributors,
and users) would spare if the administration was shifted to a
different infrastructure.

i cannot grow to like git (i still prefer darcs), but github simply
provides so many extra goodies around git, and with such a smooth
learning curve, that i think it's very much worth taking that road.

i think it'd also be worth having a separate kernel fork (repo) as
a git submodule under the openwrt git repo. it could have branches for
the corresponding openwrt branches, and with its separate commit
history it would make comparison with the mainline kernel way much
simpler than it is today.

potentially the same for some other projects as well, e.g. the
toolchain repos?


> Regarding downstream forks, would using Git also make it easier for
> people like project turris to push appropriate changes back into
> OpenWrt proper?


git checkout -b fixing-this-and-that
gitk [and cherrypick or tailor the branch with the gui as needed]
git push
go to github.com and create a pull request

the whole process can be shorter than 5 minutes, and after that anyone
can go and browse it among the open pull requests.

some more 0.02,

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Justice is not concerned with the results of the various
transactions, but only with whether the transactions themselves are
fair.”
— F.A. Hayek (1899–1992), 'Law, Legislation and Liberty', I.6.j
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Florian Fainelli]

2015-10-11 14:16 GMT-07:00 Attila Lendvai :
>> Just my 2-cents
>>
>> IF it isn't BROKENplease DON'T fix it.
>
>
> the question here is: how much time coders (maintainers, contributors,
> and users) would spare if the administration was shifted to a
> different infrastructure.
>
> i cannot grow to like git (i still prefer darcs), but github simply
> provides so many extra goodies around git, and with such a smooth
> learning curve, that i think it's very much worth taking that road.
>
> i think it'd also be worth having a separate kernel fork (repo) as
> a git submodule under the openwrt git repo. it could have branches for
> the corresponding openwrt branches, and with its separate commit
> history it would make comparison with the mainline kernel way much
> simpler than it is today.

One of the complaints OpenWrt receives a lot (aside from pushing the
actual kernel changes upstream) is that the patches are a combination
of patches applied to the kernel, and files being directly copied into
the Linux sources as-is. Although this model is not ideal for some
people, it still provides some maintenance benefit since there is only
one set of files to target multiple Linux versions.

If we are to move to an OpenWrt branch of the Linux kernel, which is
per-version of Linux (e.g: v4.1-openwrt), this creates a maintenance
difficulty for these shared files/drivers (across multiple Linux
versions), because each Linux kernel branch needs to be updated.

Are we going to expect e.g: v4.1-openwrt git history never to be
rewritten when changes to existing patches are made (look at the
Raspberry Pi kernels, this is awful)? How can we guarantee that the
same fix is easily applied throughout multiple branches? Do we also
want to start maintaining per-platform branches built on top of
v4.1-openwrt, e.g: v4.1-openwrt-ar71xx etc.?

The idealistic answer would of course be: well, get your damn Linux
changes upstream, bite the bullet now, but in few releases, you will
get most of your patches and platforms supported, so this will just be
ancient history. We all know this is not happening overnight, and
working with the upstream Linux community can be challenging for
different reasons so we still need something that is able to cope with
the fast paced embedded market with 10+ new devices everyday with just
one tiny GPIO variation, without rocking the entire way existing
platforms are supported.

>
> potentially the same for some other projects as well, e.g. the
> toolchain repos?

Yes potentially, but then, this is a shortcut we can take just because
we are natively using git, and not another SCM, and git submodules are
possible. It could become a support/maintenance nightmare if everybody
wants to start using custom snapshots all over the place.

>
>
>> Regarding downstream forks, would using Git also make it easier for
>> people like project turris to push appropriate changes back into
>> OpenWrt proper?
>
>
> git checkout -b fixing-this-and-that
> gitk [and cherrypick or tailor the branch with the gui as needed]
> git push
> go to github.com and create a pull request
>
> the whole process can be shorter than 5 minutes, and after that anyone
> can go and browse it among the open pull requests.

We are talking about something slightly different here, because
OpenWrt would switch to git does not mean that it needs to completely
moves away from being self-hosted, and moved to github. I understand
and value the benefits of github and its tools, and tend not to think
that self-hosting makes much sense these days, but others may see
things differently.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[nemesis]

On Sat, 10 Oct 2015 00:41:24 +0300, Roman Yeryomin 
 wrote:

On 9 October 2015 at 21:22, Jo-Philipp Wich  wrote:

Hi.

Moving to Git seemed to have lots of traction at the summit, and 
I'll
add my voice that this sounds like a step in the right direction 
for

OpenWrt.  I'm assuming that we would want to do a proper SVN to Git
conversion, and Eric's help on this would be great, I think.  My
discussion with Eric is over on Google+ and marked public:
https://plus.google.com/+JonathanBennett87/posts/bMPMjn7ZcJS


Why does the core system need to migrate from svn to git?



I thought everybody is using git anyway already. Are there people
still using svn?


doing something because everybody is doing so is not the best argument 
IMHO.


I would say that using git would improve quite a few things:

* it would be easier to send upstream patches
* having a good git web interface like gitlab or github would allow 
newcomers to participate more easily
* it would make life easier to the core contributors that prefer to 
work with git because git allows a very powerful development workflow 
compared to SVN


Federico
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Florian Fainelli]

2015-10-10 10:45 GMT-07:00 nemesis :
> On Sat, 10 Oct 2015 00:41:24 +0300, Roman Yeryomin 
> wrote:
>>
>> On 9 October 2015 at 21:22, Jo-Philipp Wich  wrote:
>>>
>>> Hi.
>>>
 Moving to Git seemed to have lots of traction at the summit, and I'll
 add my voice that this sounds like a step in the right direction for
 OpenWrt.  I'm assuming that we would want to do a proper SVN to Git
 conversion, and Eric's help on this would be great, I think.  My
 discussion with Eric is over on Google+ and marked public:
 https://plus.google.com/+JonathanBennett87/posts/bMPMjn7ZcJS
>>>
>>>
>>> Why does the core system need to migrate from svn to git?
>>>
>>
>> I thought everybody is using git anyway already. Are there people
>> still using svn?
>
>
> doing something because everybody is doing so is not the best argument IMHO.
>
> I would say that using git would improve quite a few things:
>
> * it would be easier to send upstream patches

I do not think it would make anything easier on that front, unless we
start putting existing git-managed projects as submodules of the
top-level openwrt.git repository, this could become fairly cumbersome
to maintain.

> * having a good git web interface like gitlab or github would allow
> newcomers to participate more easily

Fair enough, but then again, considering OpenWrt's development model,
the mailing-list should be good enough to get a grasp at what changes
are submitted/reviewed/commented on, no?

> * it would make life easier to the core contributors that prefer to work
> with git because git allows a very powerful development workflow compared to
> SVN

git-svn is kind of the best of both worlds right now.

There is a big problem with git, which is identifying what OpenWrt
release your image is based off. With subversion, it is fairly easy,
you have a revision number that keeps incrementing. With git, asking
people to give you their git-describe output might be a little harder.
On the plus side, we would know if someone had tampered with the
sources (-dirty), but we would not be able to track down changes
easily if someone just created branches and added patches there, since
these would be objects and references that are not accessible.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Attila Lendvai]

> There is a big problem with git, which is identifying what OpenWrt
> release your image is based off. With subversion, it is fairly easy,
> you have a revision number that keeps incrementing. With git, asking
> people to give you their git-describe output might be a little harder.
> On the plus side, we would know if someone had tampered with the
> sources (-dirty), but we would not be able to track down changes
> easily if someone just created branches and added patches there, since
> these would be objects and references that are not accessible.

not sure if it solves everything, but there's this:

https://github.com/sbcl/sbcl/blob/master/generate-version.sh

given a disciplined tagging strategy, it extracts a version, which
branch, and how many extra patches it has, and the end of the hash.

an example: 1.2.15.6.branch-name.5-995ba66

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“If you shut up truth and bury it under the ground, it will but grow,
and gather to itself such explosive power that the day it bursts
through it will knock down everything that stands in its way.”
— Émile Zola (1840–1902)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Steven Barth]

One important point was IIRC, migrating from one stable branch to another is 
awkward
since the history is different, so rebasing custom changes on top is painful.

All in all there was relatively overwhelming feedback of most of the people at 
the
summit that there lifes would be very much easier if the main repo was based on 
git
and there was noone who really felt the opposite.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Roman Yeryomin]

On 9 October 2015 at 21:22, Jo-Philipp Wich  wrote:
> Hi.
>
>> Moving to Git seemed to have lots of traction at the summit, and I'll
>> add my voice that this sounds like a step in the right direction for
>> OpenWrt.  I'm assuming that we would want to do a proper SVN to Git
>> conversion, and Eric's help on this would be great, I think.  My
>> discussion with Eric is over on Google+ and marked public:
>> https://plus.google.com/+JonathanBennett87/posts/bMPMjn7ZcJS
>
> Why does the core system need to migrate from svn to git?
>

I thought everybody is using git anyway already. Are there people
still using svn?

Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] SVN to GIT transition

[Jonathan Bennett]

I just received word back from Eric Raymond, author of reposurgeon and
known for many other projects.  He has limited time, but will be willing to
offer some help if we want to do a full svn to git conversion of the core
OpenWrt codebase.

Moving to Git seemed to have lots of traction at the summit, and I'll add
my voice that this sounds like a step in the right direction for OpenWrt.
I'm assuming that we would want to do a proper SVN to Git conversion, and
Eric's help on this would be great, I think.  My discussion with Eric is
over on Google+ and marked public:
https://plus.google.com/+JonathanBennett87/posts/bMPMjn7ZcJS

--Jonathan Bennett
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Jo-Philipp Wich]

Hi.

> Moving to Git seemed to have lots of traction at the summit, and I'll
> add my voice that this sounds like a step in the right direction for
> OpenWrt.  I'm assuming that we would want to do a proper SVN to Git
> conversion, and Eric's help on this would be great, I think.  My
> discussion with Eric is over on Google+ and marked public:
> https://plus.google.com/+JonathanBennett87/posts/bMPMjn7ZcJS

Why does the core system need to migrate from svn to git?

~ Jow



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Jonathan Bennett]

On Oct 9, 2015 2:21 PM, "Jo-Philipp Wich"  wrote:
>
> Hi.
>
> > Moving to Git seemed to have lots of traction at the summit, and I'll
> > add my voice that this sounds like a step in the right direction for
> > OpenWrt.  I'm assuming that we would want to do a proper SVN to Git
> > conversion, and Eric's help on this would be great, I think.  My
> > discussion with Eric is over on Google+ and marked public:
> > https://plus.google.com/+JonathanBennett87/posts/bMPMjn7ZcJS
>
> Why does the core system need to migrate from svn to git?
>
> ~ Jow

Several points were made at the meetup. I'm not the best to recap, as I
work more with the github community packages repos.

One point that was made is that upstreaming kernel patches would be
easier.  Also, most of the community uses git instead of svn, so there is
some advantage in using the more familiar tool.  Again, I'm not the best to
make the case.  Hopefully some others will jump in and contribute to the
conversation.

--Jonathan
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel