11:43 p.m.
Folks,
Now that we have this mailing list ramped up, I'm strongly considering
moving from Github to traditional patch management process where:
- Patches are prepared with git format-patch with possible cover (00)
letter if it is a patch series.
- Patches are sent using git send-email (well, you can use mutt or whatever
as long as it doesn't break the patch file).
- I'll merge accepted patches with git am.
For me pull requests bring overhead to the maintenance because I anyway
do all the patch integration from command-line. I believe that using pull
requests also decrease developer efficiency.
Issues can be still be used for bug reports and such.
/Jarkko
9:55 a.m.
On 2014-01-11 13:43, Jarkko Sakkinen wrote:
Folks,
Now that we have this mailing list ramped up, I'm strongly considering
moving from Github to traditional patch management process
This is obviously your decision and we contributors will adapt.
But I'd like to suggest one more option for consideration. How would you
like to use Gerrit for code review instead of plain text e-mail?
I found one interesting free Gerrit site that integrates seamlessly with
Github: http://gerrithub.io/
12:41 a.m.
On Sat, Jan 11, 2014 at 11:55:54PM +0100, Rafał Krypa wrote:
On 2014-01-11 13:43, Jarkko Sakkinen wrote:
>Folks,
>
>Now that we have this mailing list ramped up, I'm strongly considering
>moving from Github to traditional patch management process
This is obviously your decision and we contributors will adapt.
But I'd like to suggest one more option for consideration. How would
you like to use Gerrit for code review instead of plain text e-mail?
I found one interesting free Gerrit site that integrates seamlessly
with Github: http://gerrithub.io/
The thing that I really like in mailing list (and probably one of the
reasons why GNU projects and kernel sticks to it) is that it gives you
a single *linear* backtrackable history of decisions making. If some
change seems odd later on, a mailing list makes it easy to check the
reasoning behind it. That's really a strong benefit for everyone
involved in the project.
I think using Gerrit together with Github pull requests would make
things even worse by adding yet another weird database. In my opinion
mailing list is a better and more robust platform for patch review
than Gerrit.
Also, by using mailing list, I don't have to force people to create a
Github account in order to submit patches.
/Jarkko
1:10 a.m.
Hi Jarkko,
The mailing list patch posting is a terrible idea, as we discussed
previously. As Ryan pointed out Intel is moving forward, github and
possible gerrit. Gerrit and git hub give proper traceability which is lost
in mailing lists, top posting and commenting on subsections and the overall
comments for a commit are lost because they are not inline. Many old
projects stick to their old ways because that is the established norm for
those projects, however many are moving forward.
If you prefer cmd line integration that is your choice but the rest of the
submitters should not have to suffer because of that choice. It is still
possible to do the cmd line integration ( 4 commands) using git hub as is
currently the established norm for this project.
Br,
Brian
On Sun, Jan 12, 2014 at 3:41 PM, Jarkko Sakkinen <
jarkko.sakkinen(a)linux.intel.com> wrote:
On Sat, Jan 11, 2014 at 11:55:54PM +0100, Rafał Krypa wrote:
> On 2014-01-11 13:43, Jarkko Sakkinen wrote:
> >Folks,
> >
> >Now that we have this mailing list ramped up, I'm strongly considering
> >moving from Github to traditional patch management process
>
> This is obviously your decision and we contributors will adapt.
> But I'd like to suggest one more option for consideration. How would
> you like to use Gerrit for code review instead of plain text e-mail?
> I found one interesting free Gerrit site that integrates seamlessly
> with Github: http://gerrithub.io/
The thing that I really like in mailing list (and probably one of the
reasons why GNU projects and kernel sticks to it) is that it gives you
a single *linear* backtrackable history of decisions making. If some
change seems odd later on, a mailing list makes it easy to check the
reasoning behind it. That's really a strong benefit for everyone
involved in the project.
I think using Gerrit together with Github pull requests would make
things even worse by adding yet another weird database. In my opinion
mailing list is a better and more robust platform for patch review
than Gerrit.
Also, by using mailing list, I don't have to force people to create a
Github account in order to submit patches.
/Jarkko
_______________________________________________
SMACK-discuss mailing list
SMACK-discuss(a)lists.01.org
https://lists.01.org/mailman/listinfo/smack-discuss
2:15 a.m.
On Sun, Jan 12, 2014 at 04:10:05PM +0200, Mcgillion, Brian wrote:
Hi Jarkko,
The mailing list patch posting is a terrible idea, as we discussed
previously. Â As Ryan pointed out Intel is moving forward, github and
possible gerrit. Â Gerrit and git hub give proper traceability which is
lost in mailing lists, top posting and commenting on subsections and the
overall comments for a commit are lost because they are not inline. Â Many
old projects stick to their old ways because that is the established norm
for those projects, however many are moving forward.
I think you got it wrong here. Many projects stick to mailing list
because they work well and are easy to manage. You can even make
queries to past discussions and patch reviews while you are
offline. You cannot do that with Github and Gerrit. You don't have raw
access to your data. You have to use web interfaces to access it.
The approach of having four databases, two of which are partially
closed, does not sound feasible to me when I compare it to two fully
open databases (Git repository and mail archive). It sounds awfully
complicated.
Where have you came into conclusion that with mailing lists you lost
traceablity and how do comments get lost because they are not inline?
It's not hard to state line number in a reply. E-mail message have
these "References:" and "In-Reply-To:" fields defined in RFC 2822.
Github is still great for hosting Git repository, maintaining wiki and
reporting issues.
If you prefer cmd line integration that is your choice but the
rest of the
submitters should not have to suffer because of that choice. Â It is still
possible to do the cmd line integration ( 4 commands) using git hub as is
currently the established norm for this project.
I did not really get this part. Why using Git would be suffering for
contributors if they are already using Git?
/Jarkko
2:25 a.m.
On Sat, Jan 11, 2014 at 11:55:54PM +0100, Rafał Krypa wrote:
On 2014-01-11 13:43, Jarkko Sakkinen wrote:
>Folks,
>
>Now that we have this mailing list ramped up, I'm strongly considering
>moving from Github to traditional patch management process
This is obviously your decision and we contributors will adapt.
But I'd like to suggest one more option for consideration. How would
you like to use Gerrit for code review instead of plain text e-mail?
I found one interesting free Gerrit site that integrates seamlessly
with Github: http://gerrithub.io/
Before access rule optimizations are in place and next point release
(v1.0.4) has been I won't be making any changes to the current
workflow of submitting patches. It's good to wait for all the feedback
and arguments before making any decisions on this.
/Jarkko
3171
days inactive
3172
days old
5 comments
3 participants
participants (3)
-
Jarkko Sakkinen -
Mcgillion, Brian -
Rafał Krypa