* [KJ] bitkeeper tree for kjt patchset?
@ 2004-12-14 16:29 Gustavo Franco
2004-12-14 16:38 ` Randy.Dunlap
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: Gustavo Franco @ 2004-12-14 16:29 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 822 bytes --]
What do you think of a bk repository for kjt? I did a search and i
didn't see anything related with this topic, am i missing something ?
Reading all recent -mm announces we see that Andrew is merging acpi,
agpgart, arm, cifs and others bk trees. I think that he can merge bk-kjt
too and we'll see more testing of these patches posted at this list.
Actually, the kjt 'release process' is post the patchset to lkml when
kjt maintainer feels that it's ok, no? IMO, it can be done the same way
but asking for Andrew merge bk-kjt before release -mm kernels adding
there (bk-kjt) only reviewed patches posted at this list. Comments?
If you think that it's a good idea and there's no server to setup it
(and i guess that bkbits won't be a problem), i can host it atm.
Hope that helps,
Gustavo Franco -- <stratus@acm.org>
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [KJ] bitkeeper tree for kjt patchset?
2004-12-14 16:29 [KJ] bitkeeper tree for kjt patchset? Gustavo Franco
@ 2004-12-14 16:38 ` Randy.Dunlap
2004-12-14 17:04 ` Matthew Wilcox
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: Randy.Dunlap @ 2004-12-14 16:38 UTC (permalink / raw)
To: kernel-janitors
Gustavo Franco wrote:
> What do you think of a bk repository for kjt? I did a search and i
> didn't see anything related with this topic, am i missing something ?
IMO the maintainer should use whatever s/he feels is the best
tool for the job, whichever it is.
> Reading all recent -mm announces we see that Andrew is merging acpi,
> agpgart, arm, cifs and others bk trees. I think that he can merge bk-kjt
> too and we'll see more testing of these patches posted at this list.
Andrew can and will merge non-bk patchsets also (such as those
made with quilt or (his) patch-scripts), but he considers KJ patchsets
too risky IIRC. I may or may not be able to find the email on
that subject/discussion. You or someone can ask him again, of course.
> Actually, the kjt 'release process' is post the patchset to lkml when
> kjt maintainer feels that it's ok, no? IMO, it can be done the same way
> but asking for Andrew merge bk-kjt before release -mm kernels adding
> there (bk-kjt) only reviewed patches posted at this list. Comments?
>
> If you think that it's a good idea and there's no server to setup it
> (and i guess that bkbits won't be a problem), i can host it atm.
Please keep in mind that patchsets should still be available as
a tarball (IMO of course, but when Linus started using BK, it was
with the understanding that no one is _required_ to use BK, that
there would be alternative methods of getting the source).
So if cloning a KJ BK tree was required, I would never do it.
I just want tarballs -- which doesn't prevent the use of BK
by the KJ maintainer.
--
~Randy
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [KJ] bitkeeper tree for kjt patchset?
2004-12-14 16:29 [KJ] bitkeeper tree for kjt patchset? Gustavo Franco
2004-12-14 16:38 ` Randy.Dunlap
@ 2004-12-14 17:04 ` Matthew Wilcox
2004-12-14 17:31 ` maximilian attems
2004-12-14 17:46 ` walter harms
3 siblings, 0 replies; 5+ messages in thread
From: Matthew Wilcox @ 2004-12-14 17:04 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 751 bytes --]
On Tue, Dec 14, 2004 at 02:29:07PM -0200, Gustavo Franco wrote:
> What do you think of a bk repository for kjt? I did a search and i
> didn't see anything related with this topic, am i missing something ?
For the kind of patches in -kj, a BK tree wouldn't be a great idea.
It's the wrong usage model for janitor patches.
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [KJ] bitkeeper tree for kjt patchset?
2004-12-14 16:29 [KJ] bitkeeper tree for kjt patchset? Gustavo Franco
2004-12-14 16:38 ` Randy.Dunlap
2004-12-14 17:04 ` Matthew Wilcox
@ 2004-12-14 17:31 ` maximilian attems
2004-12-14 17:46 ` walter harms
3 siblings, 0 replies; 5+ messages in thread
From: maximilian attems @ 2004-12-14 17:31 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 733 bytes --]
On Tue, 14 Dec 2004, Gustavo Franco wrote:
>
> What do you think of a bk repository for kjt? I did a search and i
> didn't see anything related with this topic, am i missing something ?
it's up to the maintainer to choose it's tool.
i prefer free tools, afair randy too.
> Actually, the kjt 'release process' is post the patchset to lkml when
> kjt maintainer feels that it's ok, no? IMO, it can be done the same way
> but asking for Andrew merge bk-kjt before release -mm kernels adding
> there (bk-kjt) only reviewed patches posted at this list. Comments?
no the "release process" of kj is to go through maintainers,
and letting them test and merge the patches.
so taking the load of the submitters.
best regards
--
maks
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [KJ] bitkeeper tree for kjt patchset?
2004-12-14 16:29 [KJ] bitkeeper tree for kjt patchset? Gustavo Franco
` (2 preceding siblings ...)
2004-12-14 17:31 ` maximilian attems
@ 2004-12-14 17:46 ` walter harms
3 siblings, 0 replies; 5+ messages in thread
From: walter harms @ 2004-12-14 17:46 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 718 bytes --]
Matthew Wilcox wrote:
> On Tue, Dec 14, 2004 at 02:29:07PM -0200, Gustavo Franco wrote:
>
>>What do you think of a bk repository for kjt? I did a search and i
>>didn't see anything related with this topic, am i missing something ?
>
>
> For the kind of patches in -kj, a BK tree wouldn't be a great idea.
> It's the wrong usage model for janitor patches.
>
>
Hi ppl,
i agree that BK ist not the way to go since KJ patches are more random,
and will later go to other maintainer of drivers/subsystems like that
(IMHO).
But i agree with Gustavo that submitters need a better overview what is
going on. in a way that would allow to maintains to tkae notice of
changes (no idea who that can be done)
re,
walter
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2004-12-14 17:46 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-12-14 16:29 [KJ] bitkeeper tree for kjt patchset? Gustavo Franco
2004-12-14 16:38 ` Randy.Dunlap
2004-12-14 17:04 ` Matthew Wilcox
2004-12-14 17:31 ` maximilian attems
2004-12-14 17:46 ` walter harms
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.